I think Open Office or Abiword had tools to create PDFs, but I personally am unsure if they are reliable. I know TsukasaZX was working on a PDF based newsletter a while ago (I wonder what happened to it x.x) so maybe he could do it.
the tutorial already assumes you know BASIC^sounds like you already wrote a tutorial
I was about to, but I haven't actually yet. If you think you can finish it soon today, then go ahead, if not, I'll be able to handle it.the tutorial already assumes you know BASIC^sounds like you already wrote a tutorial
Would you still like me to write a tutorial/sample program article like you asked before?
I never heard of that one. I always used OpenOffice PDF converter. However, in some cases, the image locations were altered or there were some missing ones. But again, when I tried it was a MS Word 97 doc opened in OOo 2.x then converted to PDF so it was at risk to screw up.
In the days where I still went to college we used a very reliable program to do this on Mac Os that used a "print to pdf" option but I totally forgot how it's called.
The hardware of the TI-83 Plus is similar to a lot of other products: An 8-bit microprocessor of the Z80 family, a huge Flash-ROM of 512k Byte capacity, a RAM of 32k Byte size and a driver for the LCD display. You'll find similar architectures with just another balance of RAM and ROM capacity:
Edit: I think some people might consider the being able to read and write continuously to be what separates what is called "ram" and "rom" but I consider it ram since its partially accessible without needing to switch pages.Yeah, I think the problem is that we aren't talking about the same thing here.
Yeah, the doc probably has some errors, I rushed through it. What did you find exactly? Grammar error? Spelling? Broken source snippets? Hopefully not misinformation...
Some people including Calc84maniac and SirCmpwn confirmed that the 83+ effectively has 32 KB of RAM, so I guess I was right. However, I am curious, if the calc has 65536 bytes of memory addresses like this, would the second half be archive memory? Would it be problematic if we tried to write stuff there?Yeah, these others are usually used for archive. Accidental writing shouldn't be a problem, unless you HAPPEN to have flash writing unlocked and HAPPEN to write one of the command codes for flash write/erase (very unlikely, especially because we have to do carefully planned hacks to even unlock flash in the first place)
Whys is flash protected so? Why is it made so hard to unlock if it is a supposedly closed system? Like there arnt any malicious viruses flying around :PWell, it is not hard for the OS to unlock it, since it has permission. It's quite hard to do it by accident, though. For our programs to unlock flash, we have to hack into the TI-OS code that unlocks it, which is the hard part.
Well, what I am saying is that most attempted writes to archive memory are simply ignored. The only time it would have any effect is if you unlock flash and then do specific commands to the flash controller. This will never happen during normal ASM/Axe use unless you are trying very hard to do it.aaaah ok I see.
Next step is to define all our data. There will be 2 strings and 2 sprites:
:“PONG”→Str1
:“SCORE:”→Str1
:[000000000000FFFF]→Pic1
:[0000182C3C180000]→Pic1Our Title
For the score
The paddle
The ball
:“PONG”→Str1
:“SCORE:”→Str2
:[000000000000FFFF]→Pic1
:[0000182C3C180000]→Pic2In addition to the typo reported in my previous post, I would have a suggestion for next release: add the keycode table either in the command index or the doc.
Unfortunately, assembly doesn't allow you this option without some special interrupt code. I may be adding a safety feature eventually that allows you to test in a "debug mode" which adds the interrupt code to the source to allow [ON] breaks. Even though it makes the executable larger and slower, it would really just be for testing anyway.Mostly the undocumented z80 instructions will fail
I'm not sure how the NSpire handles 84+ emulation, but I've heard its not the greatest when it comes to things like this.
What is RAM? You probably know its just a bunch of memory, 65536 bytes of it to be exact on the TI-83/84.
Also does the calc really have 65536 bytes of RAM? I always thought the regular 83+ had 32768, so maybe it would be good to specify what part of that 32768 is the RAM.It has 65536 bytes of addressable memory locations. Different pages of RAM and ROM are swapped into those readable 65536 bytes when required. The total amount of RAM can be completely different.
Also does the calc really have 65536 bytes of RAM? I always thought the regular 83+ had 32768, so maybe it would be good to specify what part of that 32768 is the RAM.
Also does the calc really have 65536 bytes of RAM? I always thought the regular 83+ had 32768, so maybe it would be good to specify what part of that 32768 is the RAM.
There are 65536 addressable bytes, but only 32768 of them are used for RAM ($8000-$FFFF). Even if you're on an SE and switched in other RAM pages there, RAM can still be only from $8000 to $FFFF (everything else is used for the flash). That's my suggestion in my earlier post :)
$4000-$7FFF can be mapped to either a flash page or a RAM page, same with $8000-$BFFF, but (I think) everything under $8000 is usually used for flash. $0000-$3FFF is always ROM page 0 and $C000-$FFFF is always RAM page 0.That's the normal usage. I believe it's possible to map pages slightly differently if needed, but it's usually not needed... And some of the stranger re-mappings don't work on the TI-83+ BE, so using them would break compatibility.
Not completely sure, though. Someone correct me :D