Author Topic: Punix (Read 43193 times)

Lionel Debroux · « **Reply #60 on:** August 04, 2011, 01:36:22 am »

Hi Christopher

Good progress, as usual

christop · « **Reply #61 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:

TIfanx1999 · « **Reply #62 on:** August 22, 2011, 03:30:41 pm »

Not bad! You need to see if you can find a way to reduce of some of the background noise though.

christop · « **Reply #63 on:** August 22, 2011, 11:05:09 pm »

Quote from: Art_of_camelot on August 22, 2011, 03:30:41 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.

christop · « **Reply #64 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.

christop · « **Reply #65 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+:

Lionel Debroux · « **Reply #66 on:** March 08, 2012, 01:36:09 pm »

The initial timer value you set to 600017 might be off by one, because:

Code: [Select]

$ 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

Quote

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.

Jim Bauwens · « **Reply #67 on:** March 08, 2012, 02:04:08 pm »

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?

DJ Omnimaga · « **Reply #68 on:** March 08, 2012, 09:02:55 pm »

Oh wow that is awesome. It's great that it finally runs on real hardware.

Do you know if it will work on the TI-89 in its current state too?

christop · « **Reply #69 on:** March 08, 2012, 09:34:56 pm »

Quote from: Lionel Debroux on March 08, 2012, 01:36:09 pm

The initial timer value you set to 600017 might be off by one, because:
Code: [Select]
$ 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).

Quote

Quote
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.

Quote from: jimbauwens on March 08, 2012, 02:04:08 pm

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.

Jim Bauwens · « **Reply #70 on:** March 09, 2012, 07:39:53 am »

Thanks for the interesting info!
Now I have an other, slightly weird question

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?

Hope the questions aren't too silly

Lionel Debroux · « **Reply #71 on:** March 09, 2012, 07:59:17 am »

Quote

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

On HW2 calculators, another source of timers with a wrong rate is an uncommon state of bits 2 and 1 in port 70001F.
I haven't looked at the code, but I assume that your AUTO_INT_5 handler is short enough for the interrupt handler not to take more time than the short while between two interrupts (for which the AUTO_INT_5 would not fire again, as long as you leave SR >= 0x2500) ?
For now, nothing else that could explain the discrepancy between TIEmu and real hardware comes to my mind.

Quote

how hard would it be to port to another architecture?

Easier than porting PedroM, but the startup code and various bits interacting with the hardware (ports, screen address, etc.) would still have to be changed.

christop · « **Reply #72 on:** March 09, 2012, 10:32:42 am »

Quote from: Lionel Debroux on March 09, 2012, 07:59:17 am

Quote
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.

Quote

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.

Quote

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:

Lionel Debroux · « **Reply #73 on:** March 09, 2012, 12:53:34 pm »

Quote

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.

Good then

One bad guess, one good guess for me

christop · « **Reply #74 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.

Author Topic: Punix (Read 43193 times)

Lionel Debroux

Re: Punix

christop

Re: Punix

TIfanx1999

Re: Punix

christop

Re: Punix

christop

Re: Punix

christop

Re: Punix

Lionel Debroux

Re: Punix

Jim Bauwens

Re: Punix

DJ Omnimaga

Re: Punix

christop

Re: Punix

Jim Bauwens

Re: Punix

Lionel Debroux

Re: Punix

christop

Re: Punix

Lionel Debroux

Re: Punix

christop

Re: Punix