Tursi Posted November 9, 2010 Share Posted November 9, 2010 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! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 9, 2010 Share Posted November 9, 2010 Holy sh**....... Unbelievable man.... Unbelievable. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 9, 2010 Share Posted November 9, 2010 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 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 9, 2010 Share Posted November 9, 2010 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 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 9, 2010 Share Posted November 9, 2010 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 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted November 10, 2010 Share Posted November 10, 2010 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.) Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 10, 2010 Share Posted November 10, 2010 the 128D with that horrible, short keyboard cable. Short cable = long arms ? Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 10, 2010 Author Share Posted November 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 10, 2010 Author Share Posted November 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 10, 2010 Author Share Posted November 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 10, 2010 Author Share Posted November 10, 2010 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...) Quote Link to comment Share on other sites More sharing options...
marc.hull Posted November 10, 2010 Share Posted November 10, 2010 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 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 10, 2010 Share Posted November 10, 2010 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 Quote Link to comment Share on other sites More sharing options...
marc.hull Posted November 10, 2010 Share Posted November 10, 2010 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.) Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 10, 2010 Share Posted November 10, 2010 the 128D with that horrible, short keyboard cable. Short cable = long arms ? I LOVED that system. I had to give it up when I moved to New York for space reasons Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 10, 2010 Share Posted November 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 10, 2010 Author Share Posted November 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 10, 2010 Author Share Posted November 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 10, 2010 Share Posted November 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.