Jump to content
IGNORED

Tursi's Faire Report


Tursi

Recommended Posts

Tursi here, I was sort of asked to clarify the stuff that I was doing for the Faire. Also, I wanted to post my update links anyway. ;)

 

The first one I had to do for myself, was adding 32k to my console, as my old console was toast. I documented that here: http://harmlesslion.com/text/TI%2032k%20Mod.pdf

 

My first actual demonstration project, was my GROM simulator. I reported it worked, nobody paid much attention, but it got slightly more interest when I showed it. Project and source code here: http://www.harmlesslion.com/software/grom

 

As a valuable usage of the above, I hacked TI's Editor/Assembler to no longer require a disk to work, and put that one up here: http://www.harmlesslion.com/software/editor

 

And at last, even though it's not really quite finished yet, I released source code to my TI PS/2 adapter here: http://www.harmlesslion.com/software/adapter

 

That's all great, but the project that really blew minds was my secret surprise project - the booting of Linux on a TI. It wasn't exactly understood -- I think I spoke a little too quickly, and some visual aids probably would have helped.

 

Basically, I made a cartridge that contained, inside the cartridge, an entire Linux computer. In this case, it was a Snapper 9260 single board computer module. (http://www.designarm.com/products/snapper-single-board-computers/snapper-9260.html)

 

For the communication, I used the same chip that I used above for the GROM system. All I did was declare a "magic" address -- if you read or wrote to that GROM address, the chip would pass the data through to the serial port instead. That serial port was connected to the serial console on the Linux board.

 

And so ultimately, all I had to do was select my terminal program from the menu, and Linux came up on the TI, ready to log in and roll. Jon Guidry took some nice pictures of the screen and board for me at Facebook here: http://www.facebook.com/#!/album.php?aid=251797&id=571432449 -- Not sure if you have to log in... - second row of pics shows my stuff.

 

The beauty of this is that Linux SBCs are getting so cheap now that this is becoming a reasonable way to expand the system. My long term goals for this project are lofty, yet not actually hard to achieve. I want to turn the Linux machine into a file system device, which can then connect to anything Linux supports over USB and Ethernet, giving the TI full connectivity. I guess we'll leave the shell in too, so you can also run terminal Linux apps. ;) All this and it'll cost less than $100 in parts... with a little flexibility of size and power, it may be doable for under $50!

Link to comment
Share on other sites

As a valuable usage of the above, I hacked TI's Editor/Assembler to no longer require a disk to work, and put that one up here: http://www.harmlesslion.com/software/editor

 

Explain this please, since there was not *jack* for time during the actual "Faire" to really get into any good technical discussions.

 

Matthew

Link to comment
Share on other sites

Basically, I made a cartridge that contained, inside the cartridge, an entire Linux computer. In this case, it was a Snapper 9260 single board computer module. (http://www.designarm.com/products/snapper-single-board-computers/snapper-9260.html)

 

For the communication, I used the same chip that I used above for the GROM system. All I did was declare a "magic" address -- if you read or wrote to that GROM address, the chip would pass the data through to the serial port instead. That serial port was connected to the serial console on the Linux board.

 

Mike, will the onboard Linux be able to read and write to and from the TI disk drives? In other words, will one be able to save data and programs directly on the TI and retrieve them later, all from within Linux?

 

Walid

Link to comment
Share on other sites

As a valuable usage of the above, I hacked TI's Editor/Assembler to no longer require a disk to work, and put that one up here: http://www.harmlesslion.com/software/editor

 

Mike, is it possible to have a cartrige made with your modification using EPROMs? Maybe Jon can help us here. This would be a great replacement to the E/A cart.

 

Walid

Link to comment
Share on other sites

In answer to your question about other systems in your PS/2 adapter, I would say the Commodore 64, 128, 128D, and SX-64, as well as Atari (like my 800XL which has a ribbon.) I am not sure if PS/2 adapters exist for these units, but I can definitely see a use (especially for the 128D with that horrible, short keyboard cable.)

Link to comment
Share on other sites

As a valuable usage of the above, I hacked TI's Editor/Assembler to no longer require a disk to work, and put that one up here: http://www.harmlesslion.com/software/editor

 

Explain this please, since there was not *jack* for time during the actual "Faire" to really get into any good technical discussions.

 

Matthew

 

Heh. I know it bugs you, but I enjoy the presentation part of the faire, too. I never got to see TI presentations of any kind back in the day, and I always wanted to.

 

I think if we keep getting cool new stuff we SHOULD push for a longer faire, though, maybe a day each presentation and exhibition. ;)

 

Anyway, there's not much to note here. Since I can write GROMs now, I decided to make an Editor/Assembler cartridge that didn't need to load the Editor or Assembler files from diskette. At first, since I had no code, I started writing a DSR in GPL (and hand assembling it!). It was based on the CS1 DSR, and only supported loading image files. I got it as far as loading EDIT1, and was about to start adding support to validate the filename and load the appropriate file (this version assumed you wanted EDIT).

 

 

* Editor/Assembler Pseudo DSR for loading internal files
* Based on the CS1 DSR, as a sole GPL DSR example
* Loads at GROM >8000 (second GROM), data follows
* EDIT1 at GROM >A000 (6k)
* ASSM1 at GROM >C000 (6k) and >E000 (2k)
* ASSM2 at GROM >E800 (4k)
* Only supports those three files, and only PROGRAM LOAD
* note: only loads EDIT1. Abandoned this approach. This is still a nice reference for GPL DSR!

>8000
00 00		DATA >0000				Next DSR
80 10		DATA >ENTRY				Entry point
04			DATA >04				Name length
45 44		TEXT ':EDAS:'
41 53
00 00		DATA >0000,>0000,>0000
00 00
00 00
00			DATA >00				7 bytes of padding

ENTRY >8010
BC 5A 73	ST @>835A,@>8373 							>835A Substack
A5 56 54	DSUB @>8356,@>8354 							Compute address length byte (FRAGE)
B2 EF FF F7	AND VDP@>FFF7(@>8356),>1F 					Clear PAB error
56 1F
35 00 0A 4A	MOVE >000A TO @>834A FROM VDP@>FFF6(@>8356) PAB on FAC
EF FF F6 56
BD 5E 4C	DST @>835E,@>834C 							Buffer address
8A 4A		CASE @>834A 								Test on I/O op code
40 3D 		BR GROM@>ERROR 								Open
40 3D		BR GROM@>ERROR 								Close
40 3D		BR GROM@>ERROR 								Read
40 3D		BR GROM@>ERROR 								Write
40 3D		BR GROM@>ERROR 								Restore
40 52		BR GROM@>LOAD 								Load
40 3D		BR GROM@>ERROR 								Save
40 3D		BR GROM@>ERROR 								Delete
40 3D		BR GROM@>ERROR 								Scratch record
40 4B		BR GROM@>STATUS								Status

ERROR >803D
B6 EF FF F7	OR VDP@>FFF7(@>8356),>60 					Error illegal operation
56 60

EXIT >8043
86 7F		CLR @>837F
BC 73 5A	ST @>8373,@>835A 							Old substack
06 00 12	CALL GROM@>0012 							Return over GSR return

STATUS >804B	(not sure this is needed, but it's easy to implement)
86 EF FF FC	CLR VDP@>FFFC(@>8356) 						Status=>00
56
40 43		BR GROM@>EXIT 								End

LOAD >8052
* TODO: Determine which file (if bad, branch to error) (for now assume edit1)

* Copy EDIT1 into the buffer
31 18 00 B0	MOVE >1800 TO VDP*>834C FROM GROM@>A000
4C A0 00
83 53		CLR @>8353
40 43		BR GROM@>EXIT

 

 

However, I wandered over to Thierry's page to look something up, and noticed that he had fully disassmbled and commented the EA GROM. So although it was less cool than a DSR, it was certainly faster and more efficient to just directly patch the code with a couple of copy loops, and so that's what I did, like so:

 

 

* EDIT1 at GROM >8000 (6k)
* ASSM1 at GROM >A000 (6k) and >C000 (2k)
* ASSM2 at GROM >C800 (4k)

EDIT1 -- >01F1
31 17 00 8F	 MOVE >1700 TO @>2000 FROM GROM@>8000
9D 00 80 00

hook for ASSM -- jump at >067F
06 70 30	CALL GROM@>7030
05 66 87	B GROM@>6687  (skip over block)

ASSM1 and 2 -- >1030 (low ram line buffer overwrite)
31 18 00 8F MOVE >1800 to @>2000 FROM GROM@>A000
9D 00 a0 00
31 07 FA 8F MOVE >07FA to @>3800 FROM GROM@>C000
B5 00 C0 00
31 0F FC 8F MOVE >0FFC to @>A000 FROM GROM@>C800
1D 00 C8 00
01			RTNC

Note that the first byte of ASSM1 must be changed from >AA to >BB
so the TI doesn't think it's a GROM header. The test is fixed at offset >0654
in EACOMPLT.BIN.

 

 

And that's all I did. Now I have an E/A cartridge that doesn't need the E/A disk. I figured I might make them for people for a fee or something when life settles down a little. :)

Link to comment
Share on other sites

Mike, will the onboard Linux be able to read and write to and from the TI disk drives? In other words, will one be able to save data and programs directly on the TI and retrieve them later, all from within Linux?

 

The TI will be able to access the Linux file system. At this time, I do not intend to allow Linux to access the TI file system. This means the Linux machine can not talk to the TI disk drives. (But the TI can talk to both its native drives and Linux, so interop is preserved).

 

I thought long and hard about it, but the Linux file system is not as abstracted as I originally thought it was (I thought it was more like the TI file system, which is pretty much completely abstracted). It turns out Linux needs to know about the file system itself, and doesn't just blindly ask for files -- at least, if you want a block device file system, which I was looking into. Given the vast number of TI file system formats, I didn't want to go there, and I feel it's less important since logging into the Linux machine to do work is not expected to be a normal operation.

 

Maybe once everything else is done we can look into it, or maybe a Linux guru will get involved when it's a little closer to functional and can do that side of it.

Link to comment
Share on other sites

Mike, is it possible to have a cartrige made with your modification using EPROMs? Maybe Jon can help us here. This would be a great replacement to the E/A cart.

 

No, you have to use GROMs. That's why I built the GROM simulators! :) They need 24k of GROM space to work, so any AVR that supports that much space will do the trick. When life settles down a little I will see about selecting the smallest possible AVR (for cost) and laying out a board for it - since GROM only needs a single-sided board it's a lot easier. :)

Link to comment
Share on other sites

In answer to your question about other systems in your PS/2 adapter, I would say the Commodore 64, 128, 128D, and SX-64, as well as Atari (like my 800XL which has a ribbon.) I am not sure if PS/2 adapters exist for these units, but I can definitely see a use (especially for the 128D with that horrible, short keyboard cable.)

 

hehe. That's what I thought when I released it, but it's been out for years now without much attention. Source is out now, anyway, so in theory all someone needs to do is redo the mapping code and then let me know their intent before releasing the modified code. ;)

 

Though I did note that there's a fair bit of finicky shift handling due to the way the TI maps normal characters to both shift and fctn, not sure how much that will translate over to other machines. (I was noticing the 800XL keyboard is surprisingly close to the PC keyboard, for what keys it has, anyway... I'm mapping it the other way for another project...)

Link to comment
Share on other sites

In answer to your question about other systems in your PS/2 adapter, I would say the Commodore 64, 128, 128D, and SX-64, as well as Atari (like my 800XL which has a ribbon.) I am not sure if PS/2 adapters exist for these units, but I can definitely see a use (especially for the 128D with that horrible, short keyboard cable.)

 

All of the above exist for the C64 and more. We are a bit behind but catching up ;-).

 

http://www.ide64.org/devices.html

Link to comment
Share on other sites

Heh. I know it bugs you, but I enjoy the presentation part of the faire, too. I never got to see TI presentations of any kind back in the day, and I always wanted to.

 

I agree as long as the presentations are interesting or useful. But giving a presentation on balancing your checkbook with an esoteric XB program... Come on... That was embarrassing and a waste of time. IMO a presentation should have "take away" value, and if you don't leave a talk thinking about the topic that was being talked about, or excited about trying something, then it was a waste.

 

Look what happened when the presentations were over and the lights came up - the room exploded into talk, people walking around checking stuff out, etc. Then (clap, clap, clap) "come on people, let's get ready for the next presenter, come on, everyone up front, let's go..."

 

Not once this year or last year did I get a chance to look at your computer setup...

 

I think if we keep getting cool new stuff we SHOULD push for a longer faire, though, maybe a day each presentation and exhibition. ;)

 

Personally I don't want to sit through a day of "talks" with that being the only thing going on. There absolutely needs to be a separate room for the presentations and a *FIXED* schedule (i.e. don't let people talk for 70 minutes about why salt is white), and people can decide what they are interested in and go to those presentations. But being forced to "keep quite" and watch drawn-out presentations that I saw last year, that made me pretty pissed.

 

Anyway, this thread is not the place to soapbox about the format of the Faire...

 

However, I wandered over to Thierry's page to look something up, and noticed that he had fully disassmbled and commented the EA GROM. So although it was less cool than a DSR, it was certainly faster and more efficient to just directly patch the code with a couple of copy loops, and so that's what I did, like so:

 

That's pretty cool! So let me see if I understand you correctly. You modified the E/A GPL code to do a block copy of the utilities from your magic GROM into RAM, instead of the original code that would load that code from disk?

 

And that's all I did. Now I have an E/A cartridge that doesn't need the E/A disk. I figured I might make them for people for a fee or something when life settles down a little. :)

 

IMO, any time you put time and effort into making something in bulk for the community, you should charge for it. People don't expect this stuff for free, we all know it takes a lot of time and work to produce these new devices, and it makes it possible for "us" (anyone doing new hardware and software) to keep on doing it. Putting your code and some instructions up on a website is one thing, but "making" a physical devices is another.

 

Your patches are pretty impressive for sure. I don't think I could have done that so easily. I do not have my head around GPL very well.

 

Matthew

Link to comment
Share on other sites

 

The beauty of this is that Linux SBCs are getting so cheap now that this is becoming a reasonable way to expand the system. My long term goals for this project are lofty, yet not actually hard to achieve. I want to turn the Linux machine into a file system device, which can then connect to anything Linux supports over USB and Ethernet, giving the TI full connectivity. I guess we'll leave the shell in too, so you can also run terminal Linux apps. ;) All this and it'll cost less than $100 in parts... with a little flexibility of size and power, it may be doable for under $50!

 

 

Quick question or two Mike.....

 

Could/can SATA drives be used in this manner as well and what is the possibility of a PEB card that contains SATA and USB connections and TI handlers (I don't use the term DSR here on purpose as if I understand it correctly the SBC handles all that.)

Link to comment
Share on other sites

Mike, will the onboard Linux be able to read and write to and from the TI disk drives? In other words, will one be able to save data and programs directly on the TI and retrieve them later, all from within Linux?

 

The TI will be able to access the Linux file system. At this time, I do not intend to allow Linux to access the TI file system. This means the Linux machine can not talk to the TI disk drives. (But the TI can talk to both its native drives and Linux, so interop is preserved).

 

I thought long and hard about it, but the Linux file system is not as abstracted as I originally thought it was (I thought it was more like the TI file system, which is pretty much completely abstracted). It turns out Linux needs to know about the file system itself, and doesn't just blindly ask for files -- at least, if you want a block device file system, which I was looking into. Given the vast number of TI file system formats, I didn't want to go there, and I feel it's less important since logging into the Linux machine to do work is not expected to be a normal operation.

 

Maybe once everything else is done we can look into it, or maybe a Linux guru will get involved when it's a little closer to functional and can do that side of it.

 

This is vaguely similar then to the P112 CP/M computer-on-a-card that I installed inside my PEB that connects to the TI via the RS232 and uses the ZT4 terminal program to provide 80 column display. The TI drives are still fully accessible by the TI as well as the IDE drive connected to the P112, but the CP/M OS does not see the TI drives.

Link to comment
Share on other sites

I agree as long as the presentations are interesting or useful. But giving a presentation on balancing your checkbook with an esoteric XB program... Come on... That was embarrassing and a waste of time. IMO a presentation should have "take away" value, and if you don't leave a talk thinking about the topic that was being talked about, or excited about trying something, then it was a waste.

 

I agree with you here, but at the same time I felt that I had to be polite and attend the presentations, since I wanted to present myself. At the same time, the presenter needs to be polite and keep his presentation to the point. Bill is an excellent resource and he really has all these people and products in his head, but he has probably run into longer displays over the years due to a lack of any other presentations. He just needs to adapt again.

 

Not once this year or last year did I get a chance to look at your computer setup...

 

I will note that I spent 40 minutes hanging around your table with nothing going on, waiting to see some demos, while you guys had silently disappeared for lunch in the middle of a presentation. ;) So there's something to be said for better planning on all our parts. (Also, I didn't get lunch cause I didn't want to miss the break ;) ).

 

Personally I don't want to sit through a day of "talks" with that being the only thing going on. There absolutely needs to be a separate room for the presentations and a *FIXED* schedule (i.e. don't let people talk for 70 minutes about why salt is white), and people can decide what they are interested in and go to those presentations. But being forced to "keep quite" and watch drawn-out presentations that I saw last year, that made me pretty pissed.

 

There's no point to a separate room for presentations.. nobody will go. I think keeping speakers down to 20 minutes would go a long way towards solving that. We could be done presentations by noon, have lunch, and have four hours to mingle, collaborate, demonstrate, and hell, even work on projects together. That would totally work for me.

 

Anyway, this thread is not the place to soapbox about the format of the Faire...

 

I can! It's my thread! ;)

 

That's pretty cool! So let me see if I understand you correctly. You modified the E/A GPL code to do a block copy of the utilities from your magic GROM into RAM, instead of the original code that would load that code from disk?

 

Yep! Though my GROM is no more magic than a GRAM Kracker, it just has fewer parts.

 

I like one-chip solutions. :)

 

IMO, any time you put time and effort into making something in bulk for the community, you should charge for it. People don't expect this stuff for free, we all know it takes a lot of time and work to produce these new devices, and it makes it possible for "us" (anyone doing new hardware and software) to keep on doing it. Putting your code and some instructions up on a website is one thing, but "making" a physical devices is another.

 

I think so too, unless I don't want to support it. ;) Though the "open source" rant on the OLUG today surprised me. I'll reiterate for my own stuff (since I don't think very many else's TI stuff is currently open source and published?) that although source is available for much of my work, it is NOT okay to take my work, make a product out of it, and sell it. Hopefully though the community has learned that already (and I don't think anyone here would do that anyway!)

 

I think I forgot my license terms in the most recent uploads... absence of a license means NO license. But have to fix that...

 

Your patches are pretty impressive for sure. I don't think I could have done that so easily. I do not have my head around GPL very well.

 

Well, I don't either, but it's just another language to me. So long as I have the reference open and some examples kicking around I can get through it. I learned how to create MOVE statements when I did my GROM EA#5 converter years ago.

Link to comment
Share on other sites

Quick question or two Mike.....

 

Could/can SATA drives be used in this manner as well and what is the possibility of a PEB card that contains SATA and USB connections and TI handlers (I don't use the term DSR here on purpose as if I understand it correctly the SBC handles all that.)

 

None of the SBCs I have been looking at include SATA onboard, but you could use a USB to SATA adapter. It'd be possible to include such a thing on a card, there'd be lots of space.

 

I've been putting a little thought into packaging. I recognize some people still like their PEB, for whatever reason. There's no technical challenge to putting it on a PEB card, either, just need to lay it out (and like you suggest, a PEB card could easily map the I/O ports to physical connectors). As of last night I was toying with three possible packages:

 

-Speech Synth mod (ie: a board to install inside the Speech Synth)

-Console mod (ie: a board to install inside the console itself)

-PEB card (ie: a PEB card)

 

Also considering multiple versions... possibly different levels of SBC (more/less powerful), as well as a version with no SBC and just a serial port, for connecting to the Linux machine of your choice. At that point though, it would be the same as Fred's modified RS232 project.

 

DSR is still a valid term, since the TI needs a DSR to be able to see the devices at all. What the DSR will do is provide a transparent interface and relay the PAB to the SBC, which will parse and handle the request.

Link to comment
Share on other sites

I don't think most people understand what "open source" means... It doesn't mean "free for all," it just means "look how it works, feel free to chime in."

 

I was taken aback too... I wasn't talking about open source stuff, just that FPGA stuff can be produced more easily than original MYARC gate arrays... I made it better, or tried to anyway.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...