TIPI - TI-99/4A to Raspberry PI interface development

[Reciprocating Bill]

23 minutes ago, BeeryMiller said:

I think you are missing one piece of the equation here. 

Could be. That's why I pose it as a question: "Would shipping a couple of BCD arguments and an opcode to the PI through the registers on the TIPI, then retrieving results, be equally time consuming?" We'd be transferring a handful of bytes each way. I think that would be worth testing.

 

I doubt the TI would ever have to twiddle bits waiting for a response. My 2012 MacBook Pro running Chipmunk Basic calculates ~60 million sines and cosines per second. While the Broadcom in the PI is probably not quite that fast, whatever it's speed (I'm assuming floating point instructions in hardware) it's going to be finish a transcendental calculation and have time for a nap before the TI executes a single assembly instruction.  

 

The fastest software transcendentals I've seen on the TI are found in Cortex Basic, which is often 3-4x faster than Extended Basic/fbForth with this sort of maths.

[+FarmerPotato]

I recall a fascinating reverse-engineering of the 8087 by Ken Shiriff:

http://www.righto.com/2020/05/extracting-rom-constants-from-8087-math.html

 

I saw it in this article:

https://hackaday.com/tag/8087/

 

Quote

...He was able to see the binary representation of constants such as pi and the square root of two. There’s also an extensive series of arctangent and log₂ constants, used for the CORDIC algorithm, which reduces otherwise complex transcendental calculations to a few quick and easy bitwise shifts and adds.

 

[+Ksarul]

On 1/28/2021 at 5:10 PM, jedimatt42 said:

 

People have asked about general computation facilities on the PI, and I have rejected that as crossing a line I am not interested in supporting.

 

What I think would be cool, is actual integration of an early 80s floating point coprocessor. There were general purpose FPUs not targeted to specific CPUs.

 

There is a mostly complete design for a 68881 coprocessor board for the PEB in existence. I happen to have the rights for that one, although I haven't done much with it yet. . .

[Asmusr]

What's the use case for the FPU?

[pnr]

On 1/29/2021 at 2:21 AM, FarmerPotato said:

This code is 9900 and fits into 2K. It would run at half the speed inside a 4A ROM, worse in slow RAM. But in a F18A it could go much faster!

It does use IBM single precision, not RADIX 100. Suppose all the 4A routines in ROM were replaced by this? Would everything work after being on top of that layer?

 

Actually, it is 99000 code. The difference is not big, but the code uses such things as 32 bit addition and shifts. So it is not cut and paste, but the amount of effort needed to make it true 9900 code would not be big.

Also, John Walker (of AutoCAD fame) wrote some single & double precision routines for the 9900 that were fast for their time:
https://www.fourmilab.ch/fbench/fbench.html
I don't have source code for this, but the object code libraries can be reverse engineered of course. Happy to post the object code if anybody is interested.

Note that the RADIX 100 code has the benefit of being exact for for decimal fractions, i.e. it is much better suited to writing financial program code than IBM370 or IEEE (adding 0.01 to an amount one hundred times will not end up being 0.99 due to rounding issues).

Edited January 30, 2021 by pnr
spelling

[pnr]

On 1/29/2021 at 2:21 AM, FarmerPotato said:

@pnr   estimates the 99110 6MHz at 15 kFlops/s and concludes:

 

Quote

This compares well with the FPU chips of the late seventies and early eighties. The three main choices in 1981 were the AMD9511/i8231 from 1978, the AMD9512/i8232 from 1979 and the i8087 from 1980/81. The 99110 is from 1981 as well.

http://www.cpushack.com/2010/09/23/arithmetic-processors-then-and-now/

Please read the full post for some context. The 8087 is actually much faster than the others on plain arithmetic (add/sub, mul, div). I did not make a comparison for the transcendental functions at all.

 

If one is looking for simple & fast mathematical functions, consider using lookup tables. The original Forth needed that (it was created for software controlling telescopes); if I remember well the arithmetic was done using scaled 32 bit integers, with the each function looked up in a 64 entry table and using interpolation.

 

[Reciprocating Bill]

31 minutes ago, pnr said:

If one is looking for simple & fast mathematical functions, consider using lookup tables.

There are workarounds, to be sure. I enjoy coding stuff in assembly like the Snowflake in my avatar, an instance that requires a lot of floating point, including sines and cosines. The avatar is four superimposed levels of the snowflake, ~2800 line segments. Calculating and drawing those coordinates using the FP routines in ROM takes 1' 43" on my 16-bit console. I also save the coordinates to an 11K array (I originally stored byte-sized coordinates into word-sized memory locations due to laziness and having ample RAM, hence the double-size array). "Playback" of the snowflake then takes takes 3.6 seconds.

 

Last step was to SAVE a memory image of the array to disk (two files). Having done this once, a cut down version of the program (all the calculations cut out) LOADs the memory image back into the array, which takes about 2.5 seconds from the TIPI, then begins fast playback.  

 

Saving memory images of lookup tables for SIN and COS would be the more generalized next step. 

[Asmusr]

6 hours ago, pnr said:

If one is looking for simple & fast mathematical functions, consider using lookup tables. The original Forth needed that (it was created for software controlling telescopes); if I remember well the arithmetic was done using scaled 32 bit integers, with the each function looked up in a 64 entry table and using interpolation.

I have used lookup table for sin and cos lots of times, my raycaster being a good example. They are nice functions to look up because they are periodic and symmetric and different only by phase. A lookup takes only a couple of instructions whereas calling the TIPI of F18A would take a lot longer.

I remember I got an FPU for my 386DX BITD when I became interested in ray tracing. It did speed up things quite a lot, but it could still take hours to render a screen.

 

[+jedimatt42]

I am trying to fine tune the PI.PIO, after updating the RWAP's main Printer2PDF epson emulation code. I had some page size numbers I was using before, but I don't recall were the source for them was... I'm wondering if anyone has US fan-fold '80 column' tractor feed paper and can give me a measurement in millimeters? Looking for the post-perforation-tear-off dimensions. The default length of the page for the converter doesn't seem right, and the default width seems a little narrow. 

 

Searching the internet, there is some grey area on what the standard was, as standard US sizes changed as a result of the presidency in the 80s. Or so I've read.

 

I would gladly receive the same for typical tractor feed paper used in the UK as well, although I suspect the software has that right. 

[GDMike]

Btw, is there no way to tap into a mathematical engine on a connected raspberry pi?

I mean, like, accessing a library through python script.

 

 

 

 

Edited January 30, 2021 by GDMike

[+arcadeshopper]

I am trying to fine tune the PI.PIO, after updating the RWAP's main Printer2PDF epson emulation code. I had some page size numbers I was using before, but I don't recall were the source for them was... I'm wondering if anyone has US fan-fold '80 column' tractor feed paper and can give me a measurement in millimeters? Looking for the post-perforation-tear-off dimensions. The default length of the page for the converter doesn't seem right, and the default width seems a little narrow. 
 
Searching the internet, there is some grey area on what the standard was, as standard US sizes changed as a result of the presidency in the 80s. Or so I've read.
 
I would gladly receive the same for typical tractor feed paper used in the UK as well, although I suspect the software has that right. 

What you had before seemed to work

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

4 hours ago, arcadeshopper said:

What you had before seemed to work

Sent from my LM-V600 using Tapatalk
 

 

The units are different than what I specified before given the software upgrade and removal of my hack to set paper dimensions from environment variable in IDK what unit... probably was dots. But at least I don't have to mod the software to change the paper size. 

 

Ebay says NOS tractor feed paper was indeed 8.5" x 11" after removing the sides. 

[+arcadeshopper]

 
The units are different than what I specified before given the software upgrade and removal of my hack to set paper dimensions from environment variable in IDK what unit... probably was dots. But at least I don't have to mod the software to change the paper size. 
 
Ebay says NOS tractor feed paper was indeed 8.5" x 11" after removing the sides. 

Correct

Sent from my LM-V600 using Tapatalk

[+Vorticon]

13 hours ago, jedimatt42 said:

I am trying to fine tune the PI.PIO, after updating the RWAP's main Printer2PDF epson emulation code. I had some page size numbers I was using before, but I don't recall were the source for them was... I'm wondering if anyone has US fan-fold '80 column' tractor feed paper and can give me a measurement in millimeters? Looking for the post-perforation-tear-off dimensions. The default length of the page for the converter doesn't seem right, and the default width seems a little narrow. 

 

I assume that by "post-perforation" you mean the width of the paper between the perforations? It's exactly 215mm.

[+9640News]

Matt,

 

Nice addition and example you have for the PI.UDP capability.  I had started looking at the protocols for POP3 and SMTP recently trying to understand what may be possible for some kind of simple email communication.  I think your basic example would lend itself with the ability for an implementation possibly even within an extended basic program.  Getting a list of emails on the server I think is viable, however, I start to struggle with managing the actual size of the emails as I am looking at one mailbox where most of the emails are 100K+ to MB in size.

 

Off the top of my head, I think this would really preclude any useful implementation. Even with a SAMS, I think this would be impractical.  So, my question to you or others, does anyone concur with my reasoning or are there options I may not have considered?

 

I guess I could see the ability to send an email from one's TI, but it is the receipt of emails I think becomes the challenge unless I am missing something.

 

Any feedback is welcome.

 

Beery

 

 

 

 

 

 

[+jedimatt42]

39 minutes ago, BeeryMiller said:

Matt,

 

Nice addition and example you have for the PI.UDP capability.  I had started looking at the protocols for POP3 and SMTP recently trying to understand what may be possible for some kind of simple email communication.  I think your basic example would lend itself with the ability for an implementation possibly even within an extended basic program.  Getting a list of emails on the server I think is viable, however, I start to struggle with managing the actual size of the emails as I am looking at one mailbox where most of the emails are 100K+ to MB in size.

 

Off the top of my head, I think this would really preclude any useful implementation. Even with a SAMS, I think this would be impractical.  So, my question to you or others, does anyone concur with my reasoning or are there options I may not have considered?

 

I guess I could see the ability to send an email from one's TI, but it is the receipt of emails I think becomes the challenge unless I am missing something.

 

Any feedback is welcome.

 

Beery

 

 

 

 

 

 

Feedback: why would someone want to use email on any platform, modern or retro? Email is a broken societal construct.

 

I think all the email protocols are TCP, not UDP.

 

You'd want to use a method that leaves email on the server, but when it brings an individual message down, strips all the HTML and CSS out so you have a chance at displaying what is typically a 1k message. 

 

Encryption is typically required today, so unless you run your own email server, that's probably a non-starter.

[GDMike]

23 minutes ago, jedimatt42 said:

why would someone want to use email on any platform, modern or retro? Email is a broken societal construct.

 

FTP can get files across.. isn't that the job of email.. messaging is good though

Edited February 3, 2021 by GDMike

[+mizapf]

51 minutes ago, jedimatt42 said:

Feedback: why would someone want to use email on any platform, modern or retro? Email is a broken societal construct.

Why would I use anything else than E-Mail for asynchronous messaging? There is no service that comes even close to E-Mail, and if it were not there, someone would have to invent it.

[GDMike]

2 hours ago, mizapf said:

Why would I use anything else than E-Mail for asynchronous messaging? There is no service that comes even close to E-Mail, and if it were not there, someone would have to invent it.

But email is usually to provide a text message and a way to send or receive a file. So if messaging was available, solving the text in email problem, and files can be FTP'd, which is already in place I believe... that solves the filing issue.

 

[+mizapf]

Well, I'm just jumping up a little because I keep hearing - for the last 20 years - that E-Mail be considered obsolete.

 

[+9640News]

It's going to be a very long time before email is obsolete.  Too many things rely on email until we get digital cybernetic implants that connect us into a network for communication.   Not sure what one would then call a digital transmission to a cybernetic inbox when the user has a do-not-disturb flag or while they are sleeping.  A good series of books to read is from Ian Douglas over his 20+ books gives a fictional account of our advancements in science that lead us to future exploration and discoveries.

 

 

 

[+mizapf]

40 minutes ago, BeeryMiller said:

A good series of books to read is from Ian Douglas over his 20+ books gives a fictional account of our advancements in science that lead us to future exploration and discoveries.

 

1980s: "Can't wait for all those gadgets and things to come in the glorious future!"

2021: Listening to 80s music and watching classic sci-fi

[+jedimatt42]

Sounds like everyone is projecting their own issues on my vague comment.

 

My issue is that at the office the signal to noise ratio is less than 1:100. And that is with zero outside advertisement. 

 

My free Gmail is supersaturated with marketing. I treat it like a database. I never 'get' email when it is sent. I occasionally search my email for the receipt or itinerary that I expect to be there.

 

I pay for another freely available email service. So I have one channel where the signal to noise is closer to 6:10.

 

Signal to noise at Atariage is pretty low too. I have all forms of notification turned off. But this is the form that suites me best. A searchable database of conversations.

 

I don't think email will ever be replaced. It is part of our identity now, like your primary phone number, or postal address. The rest of the world is entitled to spam you at all these public interface points. And you can't order a pizza if you don't play the game.

[+Vorticon]

Yes, pizza is a deal breaker for me. Take my identity but not my pizza!

[+jedimatt42]

An EPROM change is coming. 

 

For FIXED record type files, the controller should increment the record number in the PAB with each READ. TIPI is currently not doing this in all cases. Tursi pointed this out. Currently TIPI is not doing this for RELATIVE access mode. 

 

The documentation from Texas instruments is ambiguous. Maybe most programs consumed the ambiguity, and so they manually increment the record number, or use SEQUENTIAL mode. 

 

A little more not-tipi testing before I share a release.