Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI 68K => Topic started by: christop on February 26, 2011, 02:19:01 pm
-
Recently I started experimenting with floating-point emulation on the 68K calculators, specifically in my own OS, Punix. (I'm new to this forum, and I haven't talked about Punix lately in other TI forums either, so for those who don't know what Punix is, it's a Unix-like OS--complete with features like preemptive multitasking and a VT220 terminal emulator--that I'm writing for the TI-92+ and maybe the TI-89)
Here's a little background on floating-point emulation. First of all, the 68000 processor has no support for FP hardware (such as the 68881 floating-point unit, or FPU). Only the later CPU's in the family (68020, '40, '60) do. However, the 68000 does have an exception vector (the so-called "F-line" or "Line 1111 emulator" exception) which allows for software FP operations. This is basically an FPU emulator, and this is what I have done. Needless to say, the software FP emulation is far slower than a real FPU by about an order of magnitude in the best case.
The 68881 and 68882 are the FPU's of choice for the 68020 (and also for the FPU-less versions of the '40), so this is what I chose to emulate. This FPU supports several integer and floating-point formats (byte integer, word integer, long integer, single-precision float, double-precision float, extended-precision float, and packed decimal float) and several addressing modes (AFAICT, the same modes as the 68000). The internal FP registers of the 6888x FPU's are 80-bit extended-precision (but stored in 96 bits), as described on this page: http://en.wikipedia.org/wiki/Extended_precision
By contrast, the TI-AMS on the 68k calcs uses an 80-bit SMAP II BCD floating-point format, which has less precision, a smaller range, and is slower to calculate than extended precision. (Single precision is smaller and faster than the others, but it also has the least precision and smallest range.)
Anyway, after a few hours of work, I implemented basic instruction decoding and the execution of a few simple FP instructions, notably FTST, FNEG, and FBcc (which is analogous to the regular Bcc instructions). Here is some demo code showing what my FPU emulator can handle so far:
| print the FP type using the current FP condition codes
printfptype:
movem.l %a0-%a3,-(%sp)
| test for nan
fbngle 1f | NGLE = not greater, less, or equal
| test for zero/not zero
fbneq 2f | NEQ = not equal
pea.l 4f | 0
bra 3f
2: pea.l 5f | x
0: bra 3f
1: pea.l 9f | nan
| test for sign (doesn't recognize negative zero)
3: fblt 2f | LT = less than
pea.l 7f | +
bra 0f
2: pea.l 6f | -
0: pea.l 8f
jbsr printf
lea.l (3*4,%sp),%sp
movem.l (%sp)+,%a0-%a3
rts
4: .asciz "0"
5: .asciz "x"
6: .asciz "-"
7: .asciz "+"
8: .asciz "%s%s\n"
9: .asciz "nan"
| here is the main entry point for the demo
| fputest() is called from a user-space driver program
.global fputest
fputest:
move #-5,%d0
| %Dn.b
fneg.b %d0,%fp0
bsr printfptype
| (d16,%pc)
fneg.x (11f,%pc),%fp1
bsr printfptype
| (An)
lea 11f,%a3
fneg.x (%a3),%fp2
bsr printfptype
| (An)+
fneg.x (%a3)+,%fp3
bsr printfptype
fneg.x (%a3)+,%fp4
bsr printfptype
fneg.x (%a3)+,%fp5
bsr printfptype
fneg.l (%a3)+,%fp6
bsr printfptype
fneg.l (%a3)+,%fp7
bsr printfptype
fneg.w (%a3)+,%fp0
bsr printfptype
fneg.w (%a3)+,%fp1
bsr printfptype
fneg.b (%a3)+,%fp2
bsr printfptype
fneg.b (%a3)+,%fp3
bsr printfptype
| -(An)
fneg.b -(%a3),%fp4
bsr printfptype
fneg.b -(%a3),%fp5
bsr printfptype
fneg.w -(%a3),%fp6
bsr printfptype
fneg.w -(%a3),%fp7
bsr printfptype
fneg.l -(%a3),%fp0
bsr printfptype
fneg.l -(%a3),%fp1
bsr printfptype
rts
11: .long 0x7fffffff,0x40000000,0x00000000 | nan
12: .long 0x7fffffff,0x00000000,0x00000000 | +inf
.long 0xffffffff,0x00000000,0x00000000 | -inf
13: .long 7
.long -7
.word 5
.word 0
.byte 3
.byte 0
This code tests a few different addressing modes (register, indirect, address register indirect, address register indirect with pre-decrement/post-increment) and integer/float formats (extended-precision, long, word, byte). My emulator cannot handle single- or double-precision or packed decimal formats yet, so I haven't tested those.
The output of this code is "-x" for a negative number, "+x" for a positive number, "+0" for zero (the test code doesn't differentiate between positive and negative zero), or "+nan" for NaN.
Here is a screenshot of this demo code in action:
(http://i3.photobucket.com/albums/y64/abbrev/Punix/fputest.png)
(You may notice that it displays "+x" for both infinities, whereas it should display "-x" for negative infinity. I already fixed this bug but didn't update the screenshot.)
Each emulated instruction takes between about 600 and 1400 cycles, which is between 8.5 and 20 KFLOPS (kilo floating-point operations per second) with a 12MHz clock rate. According to http://en.wikipedia.org/wiki/Motorola_68881 the 68881 runs at 160 KFLOPS at 16MHz, which would be about 120 KFLOPS at 12MHz. As you can see, this FPU emulator is about 1/10 as fast as a real FPU. (Take these with a grain of salt as I haven't really started on the more computationally expensive operations like multiplication and division).
Since this demo only tests simple operations (fneg is basically just flipping a single bit), most of the time in these simple FP operations is spent in decoding the instruction itself. I might also make the bare floating-point routines available to user programs (so they can do, eg, "bsr fneg" to negate (%a0) and put the result in (%a1)) to remove the instruction decoding time, but for now I'll stick with this FPU emulation.
Edit: fixed note about the bug regarding +/- infinity. I was off by one looking at the display.
Edit again: negative infinity bug is squished! I didn't check the sign for infinity and nan in the FTST code (which FNEG does implicitly)
Edit thrice: I just realized that an extended-precision value with a maximum exponent (0x7fff) is a NAN only if the fraction (excluding the MSB of the fraction) is non-zero. If only the MSB of the fraction is set, it's an infinity, not a NAN. I fixed my code to reflect this correction. Read this for (many) more details: http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf
-
Interesting, and nice to see there are still people who use 68K calculators. Until recently only me, Ranman and TC01 used them here. Unfortunately I'm ASM/C/Unix-illiterate so I would probably not understand how to use this much, but hopefully this might be useful for other people. Will the OS be able to run some 68K games on ticalc.org in the future?
Also welcome on the forums. For some reasons, I believe I saw your nickname somewhere, but that was a while ago...
-
Interesting, and nice to see there are still people who use 68K calculators. Until recently only me, Ranman and TC01 used them here. Unfortunately I'm ASM/C/Unix-illiterate so I would probably not understand how to use this much, but hopefully this might be useful for other people. Will the OS be able to run some 68K games on ticalc.org in the future?
Punix probably will not be able to run any applications that were designed for TI-AMS (TI's OS). It's basically a new OS from scratch (with some bits of low-level code from PedroM, though), so it won't be compatible with TI-AMS. It may be possible to write a TI-AMS emulator for it (kind of like Wine for running Windows applications in Linux), but I'm not too concerned about it at this point.
Also welcome on the forums. For some reasons, I believe I saw your nickname somewhere, but that was a while ago...
Nope, I think I tried registering on this site a few years ago but never completed the registration for some reason.
Since my first post I managed to get all formats (except for packed decimal) working. Here are the new test data in my demo:
11: .long 0x7fff0000,0x40000000,0x00000000 | nan
.long 0x00000000,0x00000000,0x00000000 | ?? (packed decimal)
12: .long 0x7ff80000,0x00000000 | nan (double)
.long 0x40450000,0x00000000 | 42 (double)
.long 0x7fc00000 | nan (single)
.long 0x42280000 | 42 (single)
.long 42
.word 42
.byte 0
The packed decimal data is recognized, but it's not converted to extended-precision correctly yet. Right now it is gracefully converted to NAN. I'll have to figure out a way to convert 17 BCD digits to a 64-bit binary value efficiently. Then there's the matter of converting from extended precision back to all the different formats... And of course, multiplying two 64-bit integers to get a 128-bit product, or dividing a 128-bit integer by a 64-bit integer to get a 64-bit quotient. Then there's computing natural logarithms and exponents with floating point! Fun times!
I also have to test the rest of the addressing modes too (I tested only 6 out of 12), such as address register indirect with index register and 8-bit displacement (d8,%An,%Xn). Actually, that is one of the more complicated addressing modes, so overall it's not that bad. The other equally complicated one is the same but uses the program counter instead of an address register (d8,%PC,%Xn).
-
Hi Christopher ;)
Nice to see you registering on Omnimaga, and to see you working on new stuff for Punix.
-
Hi Christopher ;)
Nice to see you registering on Omnimaga, and to see you working on new stuff for Punix.
Thanks. I'm working on Punix very slowly these days. I've got about a dozen (probably not an exaggeration) other projects, family, and school, plus I'm looking for work. I guess you could say my load average is pretty high. My brain needs more cores! :D
-
Interesting, and nice to see there are still people who use 68K calculators. Until recently only me, Ranman and TC01 used them here. Unfortunately I'm ASM/C/Unix-illiterate so I would probably not understand how to use this much, but hopefully this might be useful for other people. Will the OS be able to run some 68K games on ticalc.org in the future?
Punix probably will not be able to run any applications that were designed for TI-AMS (TI's OS). It's basically a new OS from scratch (with some bits of low-level code from PedroM, though), so it won't be compatible with TI-AMS. It may be possible to write a TI-AMS emulator for it (kind of like Wine for running Windows applications in Linux), but I'm not too concerned about it at this point.
Also welcome on the forums. For some reasons, I believe I saw your nickname somewhere, but that was a while ago...
Nope, I think I tried registering on this site a few years ago but never completed the registration for some reason.
Ah ok thanks for the info. I guess someone could write an emulator later maybe, but if there are games that don't use a single AMS command or whatever they are called on 68K calculators I bet they wouldn't be too hard to port.Also I assume of of your goal for this OS will be a much smaller file size than TI-AMS to give as much free RAM/archive as possible to the user? I wonder how much flash memory does a TI-89 and a TI-89T has in total...
As for the site, I guess you probably signed up on the other Omnimaga board back in 2006-07 but never posted. I remember at one point we had registrations disabled, though, because of spambots, then later we added a different registration step to block them, while still allowing people to sign up, but some people would never complete it. I think I might have seen you in #tcpa or something, too.
-
Would I be correct in presuming that these FP numbers conform to IEE 754 standards if they can return NaN?
-
I'm following here on your post at http://tichessteamhq.yuku.com/topic/4795/Suboptimal-code-for-shifting-a-long-long . You already know first-hand what happens, on that board, to topics related to maintenance and evolution of TI-68k development environments ;)
Yes, it would certainly be possible to make GCC generate better code. Probably not trivial though, since it requires fiddling with a very outdated version of the the well-known-as-hairy GCC code base - and modifying it further will only make the large TIGCC/GCC4TI patch harder to maintain or port to a newer version of GCC (which wouldn't even necessarily generate better code anyway - we've already seen a number of pessimizations brought by newer versions)...
But seriously, I think that if you want optimized code, write it into ASM - it's easier than modifying GCC, and guaranteed to remain effective ;)
You should also use explicit bxx.s branches (2 bytes), because just "bxx" will yield 4-byte branches :)
For the record (not directly related to the topic, but I can't commit it for now), here's the incomplete breakdown I did in ~2h by going through the patch:
* win32 changes: config.guess, gcc/config/i386/xm-mingw32.h, gcc/gcc.c, libcpp/files.c
* fiddling with default attributes: gcc/attribs.c, gcc/c-common.c, gcc/c-common.h, gcc/c-decl.c, gcc/c-lang.c, gcc/c-tree.h, gcc/langhooks-def.h, gcc/langhooks.h, gcc/system.h
* changes to the GCC built-in functions, among which is __builtin_ER_throw: gcc/builtin-attrs.def, gcc/builtins.c, gcc/builtins.def
* stkparm / regparm parameter passing: gcc/builtins.c, gcc/c-decl.c, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k-protos.h, gcc/c-parser.c, gcc/c-tree.h, gcc/function.c, gcc/function.h
* SMAP II BCD support: gcc/c-cppbuiltin.c, gcc/c-format.c, gcc/combine.c, gcc/config/m68k/m68k.md, gcc/config/m68k/m68k-modes.def, gcc/config/m68k/predicates.md, gcc/config/smapbcd.h, gcc/config.gcc, gcc/convert.c, probably gcc/c-pretty-print.c, gcc/dwarf2out.c, gcc/emit-rtl.c, probably gcc/explow.c, gcc/expr.c, gcc/final.c, gcc/fold-const.c, gcc/genmodes.c, gcc/machmode.def, gcc/optabs.c, gcc/output.h, gcc/print-rtl.c, gcc/print-tree.c, gcc/real.c, gcc/real.h, gcc/rtlanal.c, gcc/simplify-rtx.c, gcc/tree.c, gcc/tree-pretty-print.c, gcc/varasm.c
* global cast constructors / compound literals: gcc/c-decl.c, gcc/common.opt, gcc/flags.h, gcc/varasm.c
* -fno-function-cse changes: gcc/cfgexpand.c, gcc/gimplify.c, gcc/tree-ssa-dom.c, gcc/tree-ssa-pre.c
* kill global include paths, usage of environment variables, hard-coded prefixes, etc.: gcc/c-incpath.c, gcc/c-opts.c, gcc/cppdefault.c, gcc/gcc.c
* changes related to forward or backslashes in paths: gcc/c-incpath.c, gcc/toplev.c
* multi-line strings: probably gcc/c-lex.c, probably gcc/c-ppoutput.c, libcpp/internal.h, libcpp/lex.c
* constant pools, section merging, moving stuff between bss/data/rodata: gcc/common.opt, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k.md, gcc/config/m68k/m68k-none.h, gcc/config/m68k/m68k.opt, gcc/config/m68k/m68k-ti.h, gcc/flags.h, gcc/varasm.c
* register-relative addressing & global register variables: gcc/common.opt, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k.md, gcc/final.c, gcc/gcse.c, gcc/ifcvt.c, gcc/opts.c
* default to not initializing the BSS section: gcc/common.opt
* debugging support: maybe gcc/config/dbxcoff.h, gcc/config/m68k/m68k.c, gcc/dwarf2.h, gcc/dwarf2out.c, gcc/toplev.c, gcc/varasm.c
* OPTIMIZE_ROM_CALLs: gcc/config/m68k/m68k.c
* no long branches: gcc/config/m68k/m68k.c + external patcher (with a "FIXME: should be moved to GCC")
* platform-specific changes such as greater optimization, or different printf/scanf/memset/etc., or peepholes: gcc/c-format.c, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k.md, gcc/config/m68k/m68k-none.h, gcc/config/m68k/m68k.opt, gcc/config/m68k/m68k-ti.h, gcc/config/m68k/predicates.md, gcc/expr.c, gcc/opts.c, gcc/postreload.c, gcc/stmt.c, gcc/tree-object-size.c
* no-auto-octals: gcc/c.opt, gcc/c-opts.c, libcpp/include/cpplib.h, libcpp/init.c
* changes to default warnings: gcc/c-decl.c -> what with "Each undeclared identifier is reported only once" ?, gcc/c-opts.c
* reverting the removal of casts-as-lvalues: gcc/c-parser.c, gcc/c-typeck.c, gcc/tree.h
* gcc/c-pretty-print.c -> what's the second hunk ?
* reference the TIGCC infrastructure which does not make public the bug report content: gcc/diagnostic.c, gcc/version.c
* a warn_unused_result-related change: gcc/gimplify.c
* a patch related to using hard register variables as an asm input: gcc/loop.c
* gcc/sdbout.c -> ?
* inlining-related fix: gcc/tree-inline.c
* a change without comments in gcc/tree-ssa-ccp.c
* pragma poison (why ?): libcpp/directives.c
* binary numbers (0b...) support: libcpp/expr.c
* SYMSTR optimization: libcpp/macro.c
After the optimization passes in the library and startup code performed before GCC4TI 0.96 Beta 9, before GCC4TI 0.96 Beta 10 and afterwards in SVN, I found some optimization potential on a dozen library routines several weeks ago. I haven't committed because I haven't tested enough - doing so requires building up a test suite because there's none (merely compiling the examples, about a year ago, turned up 4 bugs).
-
Ah ok thanks for the info. I guess someone could write an emulator later maybe, but if there are games that don't use a single AMS command or whatever they are called on 68K calculators I bet they wouldn't be too hard to port.Also I assume of of your goal for this OS will be a much smaller file size than TI-AMS to give as much free RAM/archive as possible to the user? I wonder how much flash memory does a TI-89 and a TI-89T has in total...
Wel, it also depends on whether the game does stuff like installs its own interrupt handler. I believe TI-AMS allows user programs to run code in supervisor mode without too many restrictions (there are some restrictions on writing to Flash, though), but Punix keeps a clear separation of kernel (supervisor) mode and user mode. Also if it tries to read and write directly to the keyboard I/O ports (these are actually mapped to memory addresses in 68k), it would interfere with the normal keyboard handling code. So... it all depends on how much a program tries to do that is allowed by TI-AMS but not by Punix. In a way, it would be similar to porting a game or application from MS-DOS to Windows or Unix/Linux, since MS-DOS allows direct hardware access and the others don't.
Yes, one of my goals is to leave as much RAM and FlashROM space to the user as possible. The FlashROM is the filesystem, which leaves all of RAM for kernel buffers and user programs. Incidentally I recently tested how much contiguous memory I could allocate from userspace using malloc(). I started trying to allocate 256K (this is how much RAM the TI-89/92+ have total), reduced the amount by 1024 bytes until the malloc() succeeded, and then printed that amount (and free()ing the memory, of course!). In my current test setup, that amount came out to 202752 bytes, or 198 Kbytes. In the past I cleared out some large static memory allocations in the kernel, but there is still some kernel memory that I can free up for user programs here and there.
The TI-89 and TI-92+ have 2MB of FlashROM, I think the TI-89T has 4MB. Currently the Punix kernel uses two pages of FlashROM, or 128K, which leaves 1.875 MB for the filesystem (which I'm still writing). Some of the filesystem will be used for system binaries and configuration files, so the user should have maybe 1.5 MB for their files. Compare this to 700K (or 2.7MB on the TI-89T) of FlashROM available to the user in TI-AMS. All that math software takes up a lot of space (and poorly optimized code doesn't help either.)
As for the site, I guess you probably signed up on the other Omnimaga board back in 2006-07 but never posted. I remember at one point we had registrations disabled, though, because of spambots, then later we added a different registration step to block them, while still allowing people to sign up, but some people would never complete it. I think I might have seen you in #tcpa or something, too.
That sounds about right. I think that is what happened.
-
Would I be correct in presuming that these FP numbers conform to IEE 754 standards if they can return NaN?
Yes, you would be correct. The 68881 (and, by extension, my FPU emulator) support IEEE754 single, double, and extended precision floating-point numbers (32, 64, and 80 bit, respectively). Extended-precision values are stored in 96 bits internally and in memory, however (16 bits padding). The 68881 also supports a 96-bit packed-decimal format, which is similar to the TI BCD float format. I'm still debating whether I should support that format since it probably will not even be used.
My emulator probably won't round extended-precision values correctly since that format uses 64 bits for the fraction, and rounding requires an extra bit or two of precision to do properly. Single and double precision will probably be rounded correctly though.
-
This is just awesome! I've been following the progress of punix for years, and its great to see progress!
I've tried to compile it once, but I failed (probably I did something stupid). The screenshot show that you have already written a shell for it, which makes me even more happy :)
-
I've tried to compile it once, but I failed (probably I did something stupid). The screenshot show that you have already written a shell for it, which makes me even more happy :)
It probably wasn't you. I stupidly left Punix un-compilable since r202, which was almost a year ago now (yikes! where does the time go?). I fixed that problem 3 days ago in r211. Note that the Makefiles only work under *nix systems, or possibly with Cygwin/MinGW under Windows, since they use *nix shell commands (eg, date and tail). If you're using Windows, that might be another reason it failed. If you're using Linux, try compiling it again, and let me know how that goes.
The shell that you see is really just a mockup. It reads a command and has a big chunk of if (!strcmp(cmd, "somecommand")) statements. It doesn't search the filesystem (since there is none yet) or do anything fancy like piping or redirection. I'm using it to test various functionality of the kernel or some library routines.
Once I get a filesystem working and can execute binaries from the filesystem, I'll probably just port an existing Bourne-compatible shell to it... something like ash, zsh (not the TI-8x shells with the same/similar names :P), or Busybox. With Busybox, I would also get a lot of standard utilities built-in. W00t!
-
As a curiosity, I downloaded and compiled BusyBox 1.18.3 using the TEST_config_nommu configuration, and it produced a 519296-byte stripped binary. Obviously this would be too large for the calculator, but it also includes far more utilities than are needed:
Currently defined functions:
[, [[, add-shell, addgroup, adduser, ar, awk, base64, basename,
bbconfig, blockdev, bootchartd, bunzip2, bzcat, bzip2, cal, cat, catv,
chat, chattr, chgrp, chmod, chown, chpasswd, chpst, chroot, chrt,
cksum, clear, cmp, comm, cp, cpio, crond, crontab, cryptpw, cttyhack,
cut, date, dc, dd, delgroup, deluser, devmem, df, diff, dirname, dnsd,
dnsdomainname, dos2unix, dpkg, dpkg-deb, du, echo, ed, egrep, env,
envdir, envuidgid, expand, expr, fakeidentd, false, fgrep, find,
flashcp, flock, fold, fsck, fsck.minix, fsync, ftpd, ftpget, ftpput,
fuser, getopt, getty, grep, gunzip, gzip, halt, hd, head, hexdump,
hostid, hostname, httpd, hush, id, ifdown, ifup, inetd, init, inotifyd,
install, iostat, ipcalc, ipcrm, kill, killall, killall5, klogd, last,
length, less, linuxrc, ln, logger, login, logname, logread, lpd, lpq,
lpr, ls, lspci, lsusb, lzcat, lzma, lzop, lzopcat, makedevs, makemime,
man, md5sum, mesg, microcom, mkdir, mkfifo, mknod, mkpasswd, mkswap,
mktemp, more, mountpoint, mpstat, msh, mt, mv, nbd-client, nc, nice,
nmeter, nohup, nslookup, od, passwd, patch, pgrep, pidof,
pipe_progress, pkill, pmap, popmaildir, poweroff, powertop, printenv,
printf, ps, pscan, pwd, rdate, rdev, readlink, readprofile, realpath,
reboot, reformime, remove-shell, renice, reset, resize, rev, rm, rmdir,
rpm, rpm2cpio, run-parts, runlevel, runsv, runsvdir, script,
scriptreplay, sed, sendmail, seq, setsid, setuidgid, sh, sha1sum,
sha256sum, sha512sum, sleep, smemcap, softlimit, sort, split,
start-stop-daemon, strings, stty, su, sulogin, sum, sv, svlogd, sync,
sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd,
test, tftp, tftpd, time, timeout, top, touch, tr, true, tty, ttysize,
udpsvd, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unlzop,
unxz, unzip, usleep, uudecode, uuencode, vi, vlock, volname, wall,
watch, wc, wget, which, who, whoami, xargs, xz, xzcat, yes, zcatWith only a shell and about a dozen of the most common utilities compiled in (eg, cat, echo, ls), it would probably be about 10k-20k, which I think is reasonable.
That's a while off, though. I need to finish the filesystem (as I mentioned already) and develop a development environment for compiling programs for Punix (TIGCC has too many TI-AMS assumptions built in, and it can't output the appropriate binaries for Punix either--besides the Punix kernel itself, of course).
-
Will betas and the final version be available in binary form too? It might be a bit too much to recompile it everytime a new build comes out, but a lot of less tech-savy calculator/computer users tend to have troubles compiling softwares, as we could see with Ndless 2.0 with the flood of questions asking for help on how to compile Ndless due to errors.
-
I'm using Linux, but right now I don't have much time on my hands. I will see I can compile it somewhere later this month.
Its so cool that your system is following the POSIX guidelines, as there are so many little programs build for *nix systems that will work without changing the code.
-
Nice to see that Punix is still in development! I remember reading about it a while ago and thinking it was dead.
Good luck with this project.
-
Will betas and the final version be available in binary form too? It might be a bit too much to recompile it everytime a new build comes out, but a lot of less tech-savy calculator/computer users tend to have troubles compiling softwares, as we could see with Ndless 2.0 with the flood of questions asking for help on how to compile Ndless due to errors.
Yes, I will definitely release compiled binaries for betas and release versions. Up to this point I haven't felt that it was ready to call it a beta (I still consider it to be alpha), but now I do have a semi-usable shell and a somewhat functional kernel, so maybe I ought to release a beta to let people try it out easily in an emulator. Let me commit my recent changes (mostly to the userspace shell) and then I will release a binary soon.
-
I'm pleased to announce the first Beta release of Punix! Download the compiled TIB file here (http://sourceforge.net/projects/punix/files/betas/punix-beta0.zip/download) from SourceForge. This is a ROM for the TI-92+.
Open that file in TiEmu (or another TI-92+ emulator) and boot it up. DO NOT SEND IT TO A REAL CALCULATOR! DON'T BLAME ME FOR BRICKING YOUR CALCULATOR IF YOU DO ANYWAY! :D
You can read the full release notes (including some tips and things to do with it) here (https://sourceforge.net/projects/punix/files/betas/README.txt/download).
Let me know if you have any questions or find any bugs (besides regarding the overall incompleteness of the system). I already know a few bugs cropped up somehow during this release that weren't there before... Strange how that happens. ???
-
GLad to hear :D. I cannot test right now but I'll see if I can get TiEmu installed later. Someone should make an animated screenshot :D
-
Good ;)
-
I just tried it! It's just awesome, and it even include top,cat,date and uname.
(But for some reason cat doesn't work)
*me is a happy person
-
When you release the final version, could you make a .9xu of it and sign it using the 92+'s OS key, instead of using TIB?
I understand that TIB is just a good as a real OS file for TiEmu (and as this is a beta it's not really a good idea to try it out on a calc, as you say), but when it's actually intended to run on a calc, it'd be nice to have the signed version too.
-
(But for some reason cat doesn't work)
I hate to put it this way, but it Works For Me(tm). The shell doesn't pass any arguments to the applets, so without arguments, cat only echoes (echos?) each line that you type. Type Control-D to exit cat. This is how cat works on a "real" *nix too.
Note: I don't think I mentioned this anywhere yet (besides inside the source code), but the diamond key is Control, 2nd key is Alt, and MODE is Compose (similar to the Compose or "Multi" key in X11). Type MODE plus two characters to type a single "special" character. For example, MODE c / types a cent symbol, and MODE i " types i with an umlaut. The full list of combinations is in keyscan.c.
When you release the final version, could you make a .9xu of it and sign it using the 92+'s OS key, instead of using TIB?
To be honest, I haven't been following all of the developments in the TI calculator world very closely. Is there actually a key to sign the OS now? Yes, if I can sign it with a key to make a .9xu file instead of a .tib file, I would, at least for "production" versions (I hope there isn't a "final" version, since that implies to me that the project is unmaintained or dead).
-
I just uploaded Beta 2. This release adds support for command arguments in the shell, including support for quoting (both double and single quotes) and character escaping (using the backslash \ character), almost exactly like a real shell.
I also added the "echo" command, and "cat" can now open files and write them to standard output. Punix only understands only a few built-in filenames at the moment: /dev/{vt,link,audio,random}. You can try cat'ing any of those files but you might not like the results! You might have to reset the calculator afterwards too.
Download beta 2 (http://sourceforge.net/projects/punix/files/betas/punix-beta2.zip/download)
-
Nice to see a new update :D
When you release the final version, could you make a .9xu of it and sign it using the 92+'s OS key, instead of using TIB?
To be honest, I haven't been following all of the developments in the TI calculator world very closely. Is there actually a key to sign the OS now? Yes, if I can sign it with a key to make a .9xu file instead of a .tib file, I would, at least for "production" versions (I hope there isn't a "final" version, since that implies to me that the project is unmaintained or dead).
Yeah the keys were all factored 1.5 years ago: http://www.ticalc.org/archives/news/articles/14/145/145273.html :D
TI responded with a DMCA notice, but the TI community won with the help of the EFF.
-
Nice to see a new update :DWhen you release the final version, could you make a .9xu of it and sign it using the 92+'s OS key, instead of using TIB?
To be honest, I haven't been following all of the developments in the TI calculator world very closely. Is there actually a key to sign the OS now? Yes, if I can sign it with a key to make a .9xu file instead of a .tib file, I would, at least for "production" versions (I hope there isn't a "final" version, since that implies to me that the project is unmaintained or dead).
Yeah the keys were all factored 1.5 years ago: http://www.ticalc.org/archives/news/articles/14/145/145273.html :D
TI responded with a DMCA notice, but the TI community won with the help of the EFF.
Yup, I remember the DMCA notice, but I forgot that it was about the OS keys. Go EFF!
I'll have to add signing the OS to my Makefile sometime between now and an actual release.
-
@christop, I checked it, and you are correct (of course). It was stupid from me not to try that.
I tried both beta's, and they really look neat! Can't wait to put this on on of my calcs :)
-
So... one of the bugs in the betas is in the /dev/audio test. When you run "tests" and get to that test it just basically freezes the whole system, and you have to reset the calc. Turns out I was allocating a 4K stack for the user process, but the audio test tried to use 12K of stack for its own audio buffers. The stack is located near the bottom of memory, right above the kernel variables, so the process was overwriting many (if not all) of the kernel variables. Ouch! :banghead:
I fixed that already in my working copy, but I'm still scratching my head over another really tough bug. See this tracker page for as many details about the bug as I can think of: https://sourceforge.net/tracker/?func=detail&aid=3199268&group_id=184747&atid=910492
In all the years of working on Punix I've never had this happen before, and I just cannot figure out what is causing it. It's difficult to solve because I can't make TiEmu break on the offending address (0x0000002f) before the address exception triggers. If I could I would at least be able to see what is on the supervisor stack before it is overwritten by the address exception handler. Since it happens only after many hundreds or thousands of times calling the same system call over and over (it happens seemingly at random), I can't really step through the code in the debugger and find what is causing it.
I'd like to fix this bug for good and not just sweep it under the rug, since it'll pop back up when I least expect it.
If any of you can crack this bug, I would be most grateful! Good luck!
-
In the general case, such low addresses might be NULL dereferences... but I don't think you have any struct with a misaligned word/long field (unless you're using the packed attribute, and not using the struct type directly, otherwise the compiler should figure on its own that it needs to make multiple byte accesses)...
Judging by the values of the a2 and a3 registers you posted in the bug tracker entry on SF, it could also be a (normally aligned) word/long read at offset 0x2e from the 0x1 address (which is getting misaligned for some reason).
TIEmu does enable you to break upon address error, although after overwriting several bytes at the bottom of the execution stack. By reading those overwritten bytes, you can at least get the address of the offending instruction (minus a couple bytes, IIRC). That might enable you seeing which part of the code triggers the address error.
-
In the general case, such low addresses might be NULL dereferences... but I don't think you have any struct with a misaligned word/long field (unless you're using the packed attribute, and not using the struct type directly, otherwise the compiler should figure on its own that it needs to make multiple byte accesses)...
Just to check, I'm using the packed attribute only once for struct flashblock in flash.h:
struct flashblock {
long blockno;
char data[BLOCKSIZE];
} __attribute__((packed));
I'm pretty sure both members are word-aligned (BLOCKSIZE is an even value), and besides that, I'm not currently using the only functions that use that structure. Even in assembly code I'm pretty careful to keep addresses word-aligned, unless they point to byte/character buffers.
Judging by the values of the a2 and a3 registers you posted in the bug tracker entry on SF, it could also be a (normally aligned) word/long read at offset 0x2e from the 0x1 address (which is getting misaligned for some reason).
That's possible, and I'll look around for any jumps to an offset of 0x2e from %a2 or %a3. I can't think of any assembly code that I wrote that does a jmp 0x2e(%a2), so if that's what happened it must be compiled code.
TIEmu does enable you to break upon address error, although after overwriting several bytes at the bottom of the execution stack. By reading those overwritten bytes, you can at least get the address of the offending instruction (minus a couple bytes, IIRC). That might enable you seeing which part of the code triggers the address error.
I do have a breakpoint on the address error exception, but I want to see the contents of the supervisor stack before the exception to see if the kernel returned to address 0x2f, or if this was caused by userspace (which I doubt).
Now that I think of it, the top of the kernel stack is located at 0x4c00, and it's possible that I wrote just below the screen address during a system call, and that trashed the kernel stack. I'll see if I can move the kernel stack somewhere else and then try to replicate this bug.
-
AHA!
I moved the SSP to 0x3000 and it still goes to 0x0000002f. This means it's not caused by a write to the screen. BUT... I didn't notice this before but upon entry to the address exception handler, the SSP is 0x2ef2. Add 6 bytes to get 0x2ef8, which is what it was immediately before the address exception. This is 264 bytes below what it should be (0x3000).
Indeed, this is the contents between 0x2ffa and 0x2fff:
2ffa: 0000
2ffc: 0041
2ffe: 6f1c
That is the saved SR and PC from a trap. 00416f1c is the address following a trap #0 in userspace (with a move #3,%d0 before the trap, which means this is a read() system call--just as I suspected).
What this means is that some time before the address exception (probably right before), some exception or trap handler returned without popping all its registers off the stack (264 bytes' worth). I just need to narrow down which handler is responsible and then take it out back and shoot it. After it's dead I'll replace it with a better version. :)
-
I replaced ALL rte instructions with "jbra check_rte", and in check_rte I make sure the stack pointer is correct (0x2ffa) if the saved SR has the supervisor bit clear (which means it is returning back to user space). I also test the return address against the value 0x0000002f. If either of those tests fails, it halts right there. Guess what? Nothing failed the test, but the address exception still happens. :'(
-
Alright, after many hours of searching for the root cause, I still haven't a real clue. But I finally have a real starting place.
Inside the system call (trap #0) handler I set the interrupt level to 1 to block the system clock (level 1) interrupt from running during a system call. This seems to stop the address error from happening. This isn't an actual fix, though, since I still want the system clock to run during system calls (otherwise the system slows down due to missed interrupts). This only points the finger at the system clock interrupt handler, or some bad interaction between it and a system call.
During this time I also uncovered a handful of other minor synchronization issues and bugs, and I greatly simplified the system clock (it was a kind of kludgey mix of the int 1 and int 3 clocks), so this bug hunt wasn't a complete waste of time. None of these changes warrant a new beta, so I'll just keep looking for this pesky bug.
-
Okay, so I found the problem. It is in this line in set_state() in sched.c:
if (time_before(p->p_deadline, current->p_deadline)) {
Somehow the value 1 is passed in for p, and the p_deadline member is at offset 0x2e in the proc structure, so this is attempting to access a long value at p->p_deadline at address 0x2f. :)
So the address exception doesn't contain the return address but rather the address that some code attempted to access non-word aligned.
Now I finally bother reading M68000PRM.pdf. Here's the stack frame for address error exceptions (in pretty ASCII art :)):
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+-----------------------------------------------+
| |RW|IN| func | <-- lower address (%sp)
+-----------------------------------------------+
| access address (high) |
+ +
| access address (low) |
+-----------------------------------------------+
| instruction register |
+-----------------------------------------------+
| status register |
+-----------------------------------------------+
| program counter (high) |
+ +
| program counter (low) |
+-----------------------------------------------+
RW (Read/Write): Write = 0, Read = 1
IN (Instruction/Not): Instruction = 0, Not = 1
Therefore this address exception and the stack frame make more sense.
I still have to figure out what is calling set_state() with the value 1.
EDIT: :crazy: I just found it. I called set_run (which calls set_state) without any arguments, so whatever value happened to be on the stack was used as the value for p. FAIL :banghead:
EDIT 2: Lo and behold, that fixed the problem!! I guess I should use function prototypes more thoroughly, since TIGCC would give an error if I had a prototype for sched_run().
EDIT 3: Actually, calling sched_run() from that place (in tsleep() in process.c) was a bug itself. The process was already scheduled to run at that time so it was trying to schedule a process that was already running. I just had to remove the line completely. Now my scheduler and (due to my recent clock/timer fixes) timers are extremely stable! :w00t:
-
Congratulations!
Good coding! :D
-
Good ;)
So my wild guess about a read at offset 0x2E from address 1 actually proved to be correct...
The bug you've reported on the TIEmu SF tracker looks odd. TIEmu has no business reading data one byte off their valid locations...
-
Good ;)
So my wild guess about a read at offset 0x2E from address 1 actually proved to be correct...
Yup. I think I'll improve my exception handlers one of these days so they'll provide more information about the exception in human-readable formats (only when it happens in kernel mode. I'll want to send a signal and/or kill a process if it happens in user mode)
The bug you've reported on the TIEmu SF tracker looks odd. TIEmu has no business reading data one byte off their valid locations...
I noticed in both working and non-working (crashing) TIB files the long value 0xCCCCCCCC immediately before the SSP and PC, but in the crashing TIB, there is an additional 0xCC byte before that long value. That is probably just the last byte of a length or pointer value. Does TiEmu look for 0xCCCCCCCC as a marker or signature of sorts? If so then it would start at the previous byte for that reason.
-
Yes, TIEmu looks for 0xCC 0xCC 0xCC 0xCC. Not when importing a TIB (src/core/images.c), but in src/core/ti_hw/flash.c::find_ssp_and_pc. And if the OS's size happens to end with 0xCC (which you describe), bad things occur...
=> for the time being, just add two bytes of waste to your OS, and you should be fine. I'll fix TIEmu :)
-
This is the first time I see a quadruple post here I think, although it's fine due to the large period of time between all. That goes to tell how we need a few more 68K users. D:
I'm glad this is still progressing well. :D
-
This is the first time I see a quadruple post here I think, although it's fine due to the large period of time between all. That goes to tell how we need a few more 68K users. D:
I'm glad this is still progressing well. :D
Heh, it's actually five. :) I didn't realize I posted so many in a row when I did it. You're right, we do need more 68k folks around here.
Anyway, I just added a busy indicator to the bottom status line (next to the battery status). I think it's pretty cool watching it flicker as programs run and pause:
(http://3.bp.blogspot.com/-v4FPYHTFDhU/TXWlEQ5ChuI/AAAAAAAAEFM/Rx0LkD2CcZk/s1600/busy.png)
What does everyone think about the status icon itself? I don't particularly care for it, but it was the best I could come up with. Can anyone draw a better one? (Should I ask this in the Pixel Art and Drawing board instead?)
-
Lol I missed the other post. XD
As for the busy indicator it seems fine, although it would probably be better with an hourglass or something, which, unfortunately, might not fit. If the icon kinda blinks it might be fine, though, since it would be like that computer light that blinks when stuff is loading.
If you need a better icon, you could ask in the Pixel Art section, although sometimes it takes weeks to get a reply.
-
Ok, I changed it to a tiny hourglass. I already tried to draw an hourglass before I posted, but I didn't like the way it turned out. Speaking of the status icons, I don't really like how the hand icon looks either. I think it looks like a claw. :) I don't really have a use for the "claw" button anyway. Maybe I could use it to switch to different virtual terminals using claw+F1 through F8.
-
Ah ok, for me the icon next to the battery seemed more like a star. :P
-
I just released Beta 3, now with vfork()! This means multi-tasking works now.
The current shell can't run any pipelines or background processes, so multi-tasking is only marginally useful at this stage, but it's an important piece of the puzzle for later on.
Download the TIB file now (http://sourceforge.net/projects/punix/files/betas/punix-9x-beta3.tib/download), or read the release notes (http://sourceforge.net/projects/punix/files/betas/README.txt/download).
-
Wow, multitasking. I'm glad to see this being implemented on calc. :D
-
They were not part of a *nix OS, but multitasking on TI-68k calcs is at least ten years old (Prosit, etc.) :)
-
I remember Prosit! That was a pretty impressive multi-tasking kernel with a GUI.
-
I thought Prosit was a website lol, I guess I was wrong. I sadly never got the chance to see the page hosted on ticalc.org because half of the hosted sites were already down when I found their hosted site page.
-
I'll ask mmu_man at work the next time I see him :)
-
Is he the guy who made Prosit?
-
mmu_man did not create the project, but he worked on several applications based on Prosit.
Our discussion on IRC and his searches brought the following URLs:
* a subset of the stuff can be found on the Wayback Machine: http://web.archive.org/web/*/prosit.ticalc.org/ , e.g. http://web.archive.org/web/20021007061813/http:/prosit.ticalc.org/screenshots/index.html
* several images can be found through http://web.archive.org/web/*/clapcrest.free.fr/revol/ti68k/* , e.g. http://web.archive.org/web/20050223070933/http:/clapcrest.free.fr/revol/ti68k/prosit/shots.html
-
Ah thanks for the links and info. I should check this out. :D
-
I'm happy to announce Beta 4! This beta includes initial TI-89 support, remote terminal support (using two calculators and the "uterm" program), and user logins.
Download it now (http://sourceforge.net/projects/punix/files/betas/punix-9x-beta4.tib/download), or read the release notes (http://sourceforge.net/projects/punix/files/betas/README.txt/download).
-
Great! :D I'm glad to see TI-89 support added. Does this includes TI-89 Titanium support as well?
-
Great! :D I'm glad to see TI-89 support added. Does this includes TI-89 Titanium support as well?
Not yet. There shouldn't be too much to change to get it working on the Titanium, as far as the memory layout goes, but I haven't even tried porting to it yet.
-
Ah ok, I was wondering since the TI-89 was discontinued and most people got the 89T instead. (like me)
Good luck
-
Idea, in the wake of the discovery of Lua on the Nspire: porting Lua to PedroM and Punix :)
Yesterday evening, I tried to compile Lua for the TI-68k/AMS platform, but gave up (after several changes in the GCC4TI include files and the Lua code) when the compiler complained about stdin and stderr (and strtod and errno, but these do exist in AMS) being missing. stdin, stdout and stderr have never been implemented in TIGCC/GCC4TILIB because it's too much work, and too heavyweight for AMS native programs (due to code duplication).
However, PedroM and Punix are more POSIX compliant than AMS is :)
-
Thats a great idea!
It will be fun to see if programs made for the nSpire in Lua will run on Punix!
-
So I'm still working on the file system. There's not much to show for it yet, but I've cleaned up a lot of old code and designed a generic file system interface (so additional file systems can be added by following the same interface). I also started writing a simple RAM-based file system (tmpfs) just to get the rest of my code off the ground (I won't have to debug the block cache, the FlashROM driver, and a complex FlashROM file system all at the same time).
On the user-visible side, I added a couple new user commands in the shell: bt and crash. They're pointless for users, but they are somewhat useful for me. :)
The crash command crashes the current shell a number of different ways (address error, division by zero, chk instruction, trap on overflow, privileged instruction, line 1010 emulator, line 1111 emulator, and invalid memory access). In each of these cases, the kernel catches and reports the exception and sends the appropriate signal to the process (such as SIGFPE for division by zero), which kills the process. On the kernel side I also completed the trap handlers for all of these cases. The kernel actually can handle 3 additional traps--bus error, illegal instruction, and instruction trace--but I just didn't add them to the crash command yet. Here's an actual crash session:
(http://i3.photobucket.com/albums/y64/abbrev/punix-crash.png)
SIGILL (http://en.wikipedia.org/wiki/SIGILL) (signal 4 here) is raised when executing a privileged instruction.
Side note about the line 1111 emulator: this is used for trapping FPU instructions (all these operands start with the bits 1111) so they can be either emulated or passed to the appropriate FPU hardware (which the TI-9x don't have). I chose to emulate FPU instructions for the benefit of user programs, so running "crash 1111" will not crash the process if my FPU emulator is enabled.
The bt command prints a backtrace of the current process, meaning it shows each return address starting at the most recent (this relies on the frame pointer being used as it's intended, which isn't the case with some compiler optimization options).
-
Nice to see that you are making progress :)
Everything sounds very interesting!
-
Hi Christopher ;)
Good progress, as usual :)
-
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:
-
Not bad! You need to see if you can find a way to reduce of some of the background noise though.
-
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 :P), 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.
-
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.
-
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:
(http://i3.photobucket.com/albums/y64/abbrev/Punix/punix-grayscale.png)
- 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+:
(http://2.bp.blogspot.com/-ld-jhkg3I34/T1hQ58wY5wI/AAAAAAAAEHA/OQ0LTKJDnnE/s400/2012-03-07%2B22.24.59.jpg) (http://2.bp.blogspot.com/-ld-jhkg3I34/T1hQ58wY5wI/AAAAAAAAEHA/OQ0LTKJDnnE/s1600/2012-03-07%2B22.24.59.jpg)
-
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
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.
-
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?
-
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?
-
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! :P
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.
-
Thanks for the interesting info!
Now I have an other, slightly weird question :P
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 :P
-
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.
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.
-
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:
-
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 :D
-
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.
-
Each time I install Punix, I first install AMS 2.09 and freeflash, and then install Punix.
What about signing Punix using RabbitSign ? :)
-
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 :D).
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.
-
You say in your readme (http://punix.svn.sourceforge.net/viewvc/punix/trunk/docs/index.html) that we need to download flashos.a to build punix, but GCC4Ti included it for some time ( http://trac.godzil.net/gcc4ti/ticket/11 ), and I successfully built punix without download it separately.
Also, I've successfully compiled the beta4 for V200 with GNU/Linux, by changing the MAKE variable to make (instead of gmake) in the Makefile (gmake is the name of gnu make on BSD, I'm not running BSD ;) ), then adding some V200 preprocessor instructions to the source : http://pastebin.com/eBxnEBk5
(http://img826.imageshack.us/img826/3536/punixbeta4onv200.png)
I've not tested it on my real V200, only on TiEmu, but support the V200 should not be too difficult, I do not think it is so different from the TI92 + (probably less than between the TI89 and Titanium) ;)
-
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. :)
-
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).
Ok, I think many will understand (I have not written more, my article was already long!), and then, usually, when we speak about a BSD distro, we talk about the kernel and userland ;D I admit to not having thought we might think it would be in the kernel. I guess when the filesystem is operational, some Unix tools will not be hardcoded into the kernel (init, sh...) but they are part of your "punix" project ;)
Also, I wrote something like "Some improvements are more likely to occur than others", I think no one will blame if it is not in the kernel ;D
Thank you for reading my article, I hope that machine translation was not too hard to read (but it's probably better than my poor english) ;)
Do you know what would be incompatible with the HW1? Grayscale, sure, maybe the sound due to the 68k running at 10mhz, but there is something else?
-
Thank you for reading my article, I hope that machine translation was not too hard to read (but it's probably better than my poor english) ;)
Nah, your English is better than Babelfish.
Do you know what would be incompatible with the HW1? Grayscale, sure, maybe the sound due to the 68k running at 10mhz, but there is something else?
Yeah, the sound would play slowly on HW1. The system real-time clock would also run slowly, and it would be affected by the battery strength, but that can be fixed somewhat with the adjtimex system call (currently planned) to adjust the system clock frequency. Even grayscale is possible on HW1, but I would have to add support for it in Punix. I can't think of anything else off the top of my head that would be incompatible.
-
Grayscale is easier and faster on HW1 than on HW2, in fact :)
The main thing is to set port 600010 appropriately, and the LCD controller's DMA does the job. See the source code of the grayscale routine in GCC4TI. VTI doesn't emulate the HW2 way of making grayscale, so you'll have to treat it as HW1.
It's not possible to make an accurate timer on HW1, but it may indeed be possible to alleviate the problem.
-
More than a year after the last release, I'm happy to announce the release of Punix beta 5!
All files: http://sourceforge.net/projects/punix/files/betas/
TI-89: punix-89-beta5.89u (http://sourceforge.net/projects/punix/files/betas/punix-89-beta5.89u/download)
TI-92+: punix-9x-beta5.9xu (http://sourceforge.net/projects/punix/files/betas/punix-9x-beta5.9xu/download)
Source: punix-beta5.tgz (http://sourceforge.net/projects/punix/files/betas/punix-beta5.tgz/download)
I also noticed that Punix was recently added to the Levenez Unix History (http://www.levenez.com/unix/) page! :o
-
oh thank you, I'll try it as soon as possible !
It's great to see Punix on the Levenez Unix History page! :)
-
Very nice!
Maybe I can get it to run in http://tiplanet.org/forum/viewtopic.php?p=123113&sid=908abe877410032af582a58723441e76#p123113 :D