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 - christop
16
« on: March 20, 2012, 03:05:47 pm »
Ah yes, I guess you're right about flashos.a. I think that's left over from when I was using TIGCC. I'll update my documentation now.  Good job building Punix for the V200. I think the V200 is basically the same as the TI-92+ so I haven't bothered trying to build Punix for it. It's good to see that it works fine, though. Regarding your LinuxFR article: I know I mentioned in my Punix blog that I am trying to make a speech synthesizer, but I didn't mean that it's going to be part of Punix itself. It's just going to be a program that will run under Punix (or under TI-AMS if someone wants to port it). I don't want people getting the impression that the kernel is going to have a speech synthesizer, though that would be kind of cool.
17
« on: March 13, 2012, 08:29:10 pm »
How would I use fixed-point? Doesn't it have to be floating-point?? Fixed-point is just using values multiplied by a scaling factor, usually a power of two for efficiency. Say you have a 16-bit integer and you split it into 8 bits for the integer part and 8 bits for the fractional part. That's the same as multiplying a real (floating-point) number by 256 and then taking the integer portion. Then to add two fixed-point numbers, just add them as usual. To multiply two numbers, multiply them as usual and then divide by 256. To divide, multiply the numerator by 256 and then divide by the denominator. Since you probably won't want to write your own cosine and sine functions, you can still use the same ones after converting the fixed-point number back to floating point (cast it to float and divide by 256). Of course, you can use more than 8 bits for the integer and fraction parts, and they don't have to be the same. How many bits you use depends on the range and precision you need and the size of the available integer types (16 and 32 being the most common). Could you explain "shearing" to me?
EDIT: But it involves skewing! How would I do that??
Shearing is basically like taking a rectangle and moving the top and bottom in opposite directions so that you end up with a parallelogram. The top and bottom are the same length, and the parallelogram has the same height as the original rectangle, but the sides are longer than the original. Here's a little illustration showing a rectangle getting x-sheared: original:
xxxxxx
xxxxxx
xxxxxx
xxxxxx
x-sheared (alpha=-1):
xxxxxx
xxxxxx
xxxxxx
xxxxxxY-shearing is the same but along the y axis. I can't help with an implementation for several reasons, such as that I don't even know what pixel format it uses. Besides, that link I gave you has an implementation in a Pascal-like language and one in Matlab.
18
« on: March 13, 2012, 03:43:23 pm »
I tried rotating a picture by getting all the points. It works, but is really slow. Could I speed this up?
Are you trying to rotate a raster (bitmap) image? That's understandably going to slow because a raster image contains many points. It might be a lot quicker to rotate it by shearing the bitmap three times: http://www.ocf.berkeley.edu/~fricke/projects/israel/paeth/rotation_by_shearing.htmlOr you could try using fixed-point instead of floating-point arithmetic using your current algorithm because your system might not have floating-point hardware, so it has to be emulated in software (which is slooooow).
19
« on: March 13, 2012, 11:25:48 am »
3rik went into a lot of detail, but let's keep it simple here.
First of all, let's forget that you have a set of points and assume you have only one point to rotate about the origin. For this all you need is these two formulae:
x' = x*cos(theta) - y*sin(theta)
y' = x*sin(theta) + y*cos(theta)where x and y are the coordinates before rotation, x' and y' (x prime and y prime) are the coordinates after rotation, and theta is the angle to rotate the points.
If you need to rotate your point about another point instead of the origin, you just have to subtract the center point from the rotating point and then add the center point back after the rotation:
x' = (x-x0)*cos(theta) - (y-y0)*sin(theta) + x0
y' = (x-x0)*sin(theta) + (y-y0)*cos(theta) + y0where x0 and y0 are the coordinates of the center point. (Obviously if (x0, y0) is (0, 0), the formulae are equivalent to the first set of formulae above.)
Now, you want to rotate a set of points. That's easy. Just evaluate the formulae above for all points in your scene. Since all points will be rotated by the same angle, you can calculate sin(theta) and cos(theta) once for all points. Here's some pseudo-code to illustrate what I mean:
c = cos(theta)
s = sin(theta)
for each point (x, y):
x' = x*c - y*s
y' = x*s + y*cYou'll have to deal with connecting them with lines after they're rotated. I won't go into details on how to do that, but you could take one list of coordinates and return a second list of coordinates after they're rotated (say, L1 is the list of original points, and L2 is the list of rotated points), and then have another list that contains pairs of subscripts ("from" and "to" subscripts) into one of those lists.
20
« on: March 10, 2012, 01:20:27 pm »
Each time I install Punix, I first install AMS 2.09 and freeflash, and then install Punix. What about signing Punix using RabbitSign ?
Of course. I first had to figure out how to convert the tib file to a 9xu file (which turned out to be easy with freeflash's tib2xxu program). Then last night I successfully signed it with rabbitsign using key 01. I was happy to see the bootloader accept the signature. It's definitely faster to upgrade the calc with my 96KB system than with the 1024KB AMS. Now I'm trying to add the signing step to the makefile so the signing is done automatically. Back to the clock speed issue... I compared my start.s to PedroM's Boot.asm and found that I was not disabling The Protection correctly before it wrote to $70001f, so it didn't have any effect. I hope I got it right this time (it seems to set the clock speed now). On a different subject, I've thought about attaching piezo speakers, and maybe a volume dial/switch, to my calc so I can play audio without having to plug in external speakers. I also thought about adding a PS/2 port to my calc in case I add an AT keyboard/mouse driver. Help! I'm turning into Kerm Martian! (Not that that's necessarily a bad thing  ). Edit: I can't figure out what is happening with address error exceptions. I'm intentionally crashing a userspace program (to test exception handling) with an address error by accessing a word at 0x4321. It works fine and as expected in TiEmu but causes a kernel panic on a real calc. All other exceptions (eg, illegal instruction and division by zero) work fine. The address error stack frame doesn't even make sense on the real calc. It says the program counter is the beginning of my Int2 handler (0x4124ca, which consists of two move instructions and an rte and is triggered all the time without issue). The status register (0x2101) suggests it was inside the kernel, but as I mentioned, I triggered the exception from user mode. See the full exception outputs from tiemu and the real calc: real calc:
address error exception
function code: 0x4e76
access address: 004321
instruction register: 0x4e73
status register: 0x2101
program counter: 4124ca
tiemu:
address error exception
function code: 0x0011
access address: 004321
instruction register: 0x31fc
status register: 0x0004
program counter: 4257acIt didn't panic in tiemu because the status register was in user mode (as it should be). Only the offending process was killed by a SIGBUS signal.
21
« on: March 09, 2012, 11:43:45 pm »
Strange, I ran Punix for nearly a whole day, and the clock was relatively accurate. But then I hard reset it (pulled a battery out) and the clock is slow again. There must be something more to the story than those two bits in port 70001f.
Each time I install Punix, I first install AMS 2.09 and freeflash, and then install Punix. Perhaps AMS is setting some port that Punix doesn't. I'll see if PedroM works correctly and which ports it writes to.
22
« on: March 09, 2012, 10:32:42 am »
It's possible that I set the value off by one, but I don't think it's likely. I set the timer value to the maximum, 255, so the interrupt should fire every other time the timer increments, ie, 16384/2 = 8192. It does so in TiEmu. OK. The value you wrote in your previous post was so perfectly 2/3 of the intended value that it might just have been due to the problem I mentioned
Except that value affects only Int5, not Int1 and Int3, but as I mentioned, all three are slow. On HW2 calculators, another source of timers with a wrong rate is an uncommon state of bits 2 and 1 in port 70001F. I think this was the problem. I set those bits to 11 in the startup code, but somehow they must've gotten set to 00 somewhere else, which slows down OSC2 to about 2/3 of the normal rate, which is exactly the symptom I was experiencing. Now I set them back to 11 in my poweroff routine, and the clocks are very accurate. How hard would it be to make Punix run on other hardware, say an old 68k mac?
Is it too dependent on the hardware of a 92+, or is it in theory possible?
Now, continuing on this .. how hard would it be to port to another architecture? Everything is possible, in theory.  All of the device drivers and startup code would have to be rewritten to run on an old 68k Mac. Porting it to another architecture would also require that, in addition to rewriting all of the assembly code, which currently makes up about 13% of the line count in Punix. Overall, I think it would be easier to port a mature *nix system, such as Linux or NetBSD, than trying to port Punix. Both Linux and NetBSD should be able to run on a NOMMU system with as little as a few MB of RAM. At work I'm actually working on a uClinux system running on a 166MHz Coldfire processor (a descendant of the m68k) with only 8MB RAM and 8MB FlashROM (or some other type of nonvolatile solid-state memory). Edit: I also fixed shutting off the LCD. The problem was that I wasn't shutting off the LCD! I was only setting the row sync (RS) to 0b1111, which stopped the LCD from "scanning" all rows of pixels, which made it stop at one row of pixels. Also, fixing the OSC2 clock fixed the flickery grayscale issue. Last, I discovered an issue with the link device driver when a program writes to it and nothing is connected to the calculator. When the program closes the device file, it tries to drain the write buffer, but since nothing is accepting the data, it hangs there until something does read it. This happens also when you try to kill the program with ctrl-C. I either need to have a short timeout, after which the write buffer is discarded, or let the program close the file without waiting for all data to be written. Edit 2: Short demo of Punix playing music:
23
« on: March 09, 2012, 10:15:25 am »
Yep, I'm referring to Punix. I don't mention much about the VT100 emulator, but here's the Punix thread: http://ourl.ca/9392
24
« on: March 08, 2012, 09:34:56 pm »
The initial timer value you set to 600017 might be off by one, because:
$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
8192*2/3
5461 bc? You heathen! dc is the One True Calculator!  It's possible that I set the value off by one, but I don't think it's likely. I set the timer value to the maximum, 255, so the interrupt should fire every other time the timer increments, ie, 16384/2 = 8192. It does so in TiEmu. I think OSC2 (the base oscillator for int1, int3, and int5) is just running slow because my real-time clock (which is incremented in int3) is running slow, at about 72% of real time. I estimate it's 72% (my previous estimate was 67%) because I left Punix running for almost 9 hours today at work, but only 6.5 hours elapsed in Punix-land. Int1 and int3 are synchronized with each other (int1 running at 1/256 the rate of int3), so int5 must be synchronized too. I think I can live with the slow clock since I am already planning to add support for adjusting the real-time clock frequency (ie, by adding slightly more than 1 second each int3). There's also a little issue with the screen not shutting off when I turn off the calculator, but that should be easily fixable. The screen status bit is 60001D:4 on HW1 (on HW2, it's a bit for the contrast...), 70001D:1 on HW2.
I'll look into my poweroff routine to make sure I'm setting/clearing the right bits. Very nice progress!
Really makes me want to install this on my 92+
Also, is the top that is running a direct port, or did you modify/make your own?
Thanks! It's not ready to use for real yet (for one, there's no filesystem in this version). I wrote my own top program. It's really simple, though: it doesn't attempt to minimize writes to the screen by printing only differences between updates (as some versions appear to do), and it doesn't put the terminal into non-canonical input mode (so you have to type ENTER or ctrl-D before top will read user input). Also, different *nix systems have different ways to access information about the system and about individual processes, and I chose to follow the FreeBSD conventions here (ie, using the sysctl syscall). DJ_O: It should run on the TI-89 (but not the Titanium) since the hardware is almost identical to the TI-92+, and it works just as well in TiEmu. If anyone wants to donate a TI-89 to me for testing, I'll gladly accept it. Otherwise I'll just have to buy one myself.
25
« on: March 08, 2012, 01:27:55 pm »
I've been posting my progress mostly on Cemetech lately, but here's a summary of what I've done since last time: - M68881 FPU emulator is still under development, but a few instructions work well so far: fmove, fadd, fmul, fsub, fabs, and fneg. Execution speeds for fadd/fsub and fmul are faster than the equivalent operations in PedroM (which uses a slower BCD floating-point format to be compatible with TI-AMS).
- Four-level grayscale! Currently only HW2 is supported, but that's probably more common than HW1 anyway. Text glyphs are also anti-aliased to take advantage of grayscale. Here's an early screenshot of grayscale:
 - The scheduler has been tested quite thoroughly by now. I recently stress-tested it by running a few dozen busy processes at various "nice" levels, while also playing audio. Surprisingly, playing audio at the base nice level (zero) with 43 busy processes resulted in smooth, skip-free sound.
- I'm playing with the idea of adding a PS/2 driver which will allow a user to plug a regular keyboard into the link port (with an appropriate adapter) and start typing away on it. This is a low-priority feature, but I'm the most exited about it at the moment.
- I finally installed Punix on my TI-92+. It works well but has some glitches that don't show up in TiEmu. There's no major problems, but the biggest issue is the real calculator is a lot slower (about 33%) than I was expecting or hoping for. While I can compensate for this speed difference in my timer code, the audio driver becomes practically unusable (programs expect it to play at 8192Hz, but it really plays at about 5461Hz, so all sounds are noticeably slow). There's also a little issue with the screen not shutting off when I turn off the calculator, but that should be easily fixable.
Here's a picture of Punix on my TI-92+: 
26
« on: March 07, 2012, 07:13:19 pm »
As a self-proclaimed VT100 expert, I have to say this is impressive! Yours is nicer than my VT100 emulator too: mine is only monochrome (though I recently added grayscale glyphs) and only 60 columns by 20 rows. Each character is 4x6 pixels (the screen 240x128). Mine doesn't even support setting top and bottom margins for the scrolling region, or double-width and double-height lines! I found it to be sufficient for some full-screen applications like "links", though. How did you implement your emulator? Did you write a state machine? I used the pages at http://vt100.net/emu/dec_ansi_parser (which contains a very useful state diagram) and http://vt100.net/docs/vt100-ug/ to write my emulator. I haven't tried connecting mine to a Linux system yet, but I plan to do that before too long (if I can figure out how to make TiEmu act like a virtual serial port).
27
« on: September 07, 2011, 01:20:42 am »
So I tried a modified delta-sigma conversion again recently, and I got pretty good results. It has a much higher dynamic range than the audio in the video I posted. Most of the noise is in the high frequency range, so you definitely need to use a low-pass filter for the audio output. I found that a good cut-off frequency (with a 6dB-per-octave filter) is half of the Nyquist frequency, or 2048 Hz. The result is similar to a slightly out of tune AM radio station.
Even with this conversion method and low-pass filtering, I wouldn't call the audio enjoyable to listen to. It's only 16kb/s, after all. I foresee the audio output being used for chiptune music or sound effects in games perhaps, much more so than for converted waveform music.
28
« on: August 22, 2011, 11:05:09 pm »
Not bad! You need to see if you can find a way to reduce of some of the background noise though.
It's already as noise-free as I could make it (short of making it silent ), since it's 1-bit sound. I'd like to see if anyone else can do a better job at converting audio to 1-bit/8192Hz sound. I have a few more ideas of my own to improve the sound quality but haven't tried them out yet. I've already tried most of the common conversion methods too: PWM, PPM, delta-sigma, etc. The sample rate is simply too low to make those very effective, though.
29
« on: August 22, 2011, 01:31:19 pm »
I recently fixed my audio interrupt latency problem (which was manifested as skips/jitter in sound playback). I also wrote a little program to convert audio to 1-bit sound with decent quality. Here's a demo video of a TI-89 (running in TiEmu) playing a song:
30
« on: August 07, 2011, 10:09:55 pm »
With a calculator handy
The basic fact you end up using is that any number x can be represented in base z as ∑aizi
With the exception of when z = 0 or |z|=1, of course
Awww, no nullary number system? With base 1, do you use as many digits as will add up to the value? For example, is 7 decimal equal to 1111111 unary? I also don't see how fractions can be represented in unary.
|
Show Posts
