Jump to content

Search the Community

Showing results for tags 'RS232'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type

Marker Groups

  • Members


  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion
  • The Homebrew Discussion's Topics


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Product Groups

  • Subscriptions

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 8 results

  1. Web99 ===== This program is freeware. Copyright by Klaus Lukaschek 2015-12-28 Version 0.5 Beta 4 *New Introduction ============ The idea of this program is to help you in 3 different areas: - get rid of duplicate Disk Images and Ti Files. - make your Ti Files searchable, even from the TI-99 - access and manage your Ti File Collection from your TI-99 This Tool is programmed in Visual C#, it's .NET Framework 4 Client Profile based and therefore runs on Windows XP or later Windows Versions. It is compiled to run on both x64 and x86 platforms. You will need to have .NET Framework 4 or later, it is sufficient to only have the 'Runtime' installed. The index and search technology that got integrated into the project is the .NET port of Lucene. A serial port (or any USB2Serial solution) is required only if you want to communicate with your TI-99 or if you want to use the Search from your TI-99. Why? ==== Whenever I am on a TI meeting or hitting a new website, it seems that I get tons of disk images, that I manually have to compare against my current collection. I got tired of doing this over and over again. There must be an automatic way to check the new files for their uniqueness. Imagine, having to find a certain Ti File - mostly a program - in your collection. How do you know on which Disk Image and in which Path it is stored? The problem is, a Windows search tool can't look into your Disk Images and gives you a list of Ti Files with the name "ROS". Maybe you would even know the size in sectors, its Filetype, the Ti Diskname or some other Meta Data. However for your Pc your disk image is simply a Pc file with a Pc filename, a Pc filesize and some Date Information. Until now, most people started Ti99Dir or TiImageTool and opened one Disk Image after another until they hit the Ti File. How much cooler would it be if you have something like Google, customized for your TI-99 Disk Images? What if Google would know exactly all TI relevant information about your Disks, and it would let you search by Ti Filename, by Ti Diskname, by Ti Filetype, Size and more. Well, Web99 is trying to become exactly that search engine for you. It is even trying to become such a search engine usable from your TI machine. Uniqueness ========== For each stream of data you can calculate a Hashkey. I am using the MD5 128bit algorithm to generate those. This means the result is a 128bit length Key, usually this is written in hexadecimal form and therefore such a key looks like '88ec1168efbd75617d28fa3ade124dfa'. For our purpose this lenght should be more than enough to ensure uniqueness. Based on the same input, the same Hashkey is produced. So if you have two files, calculate their Hashkey and they are different means that those files are not identical. So comparing becomes a lot easier, we simply need to calculate Hashkeys once for everything and compare those with each other. The dupes will show up immediately because they have the same Hashkey. The check for uniqueness can be done on all kind of levels. So I started the idea to calculate an unique identifier for each Disk Image and every Ti File on my Pc, based on their binary content and meta data. A program would be able to calculate these for a new set of Files and compare each against your collection. Version 0.5 Beta 4 from 2015-12-28 Web99_2015-12-28_v0.5_Beta_4.zip Version 0.5 Christmas Edition from 2015-12-25 (with a complete Index) http://www.ti99.eu/web99/Web99%20%5B2015-12-25%5D%20v0.5%20xmas%20edition.zip Other Versions: 2015-11-24 Version 0.5 Beta 2 [with Classic99 Export] 2015-11-22 Version 0.5 Beta 2015-11-12 Version 0.4d 2015-11-09 Version 0.4a 2015-11-09 Version 0.4 2015-06-04 Version 0.2 2015-05-24 Version 0.1c 2015-05-17 initial public release - Version 0.1
  2. How many lines of Atari BASIC is required to make the Arduino shield from the last blog post talk? 3 lines - type some text, hit return, send text to the 850 interface and repeat. The Arduino receives the text, does a little reformatting, then sends that string to the XFS5051CE chip for speech synthesis. This isn't just for the Atari8, any computer with an RS232 port can be made to chit-chat. The Shield is going to use the Serial pins 0 and 1 to talk to the Arduino. A TTL to RS232 converter is needed to make the connection to the computer. A SoftwareSerial port is required. Connect the Ground and 5V power to the converter. The RX pin on the converter should be connected to digital pin 5 and TX to pin 6. Also, remember that the high side of the busy light was connected to Analog pin5 because I couldn't get the serial output of the chip to work. When the light is on, its busy. The Arduino is going to have to be programed to accept ASCII code. I try to copy as much code as I can. This time I found a bit of code in "Beginning C for Arduino" by Ph.D. Jack Purdum. The program calls a function to read characters from the software serial port into a string array until and EOL is encountered. I couldn't get it to exit the function until I moved the return command a couple of brackets up. I know if a loop is exited in Atari BASIC, you have to make sure you POP the stack or bad things can happen. The C program seems to work fine so maybe the return belonged where I put it. The program starts off by setting up the hardware and then speaks a test sample. Sometimes when powering up the arduino you will need to hit reset on the shield(and set RUN switch) and then reset on the Arduino. After you hear the test you know the system is setup and hooked to the amp or headphones. Its ready to start accepting string data. The ReadLine function gets a character from mySerial port. If it is not a EOL then it adds the character to the string. If it reads an EOL then a null character is added to the string. Now it has the line of text and exits the function. The SpeechSynthesys library has the functions to add the text to the formatted string for speech. The Arduino then checks the wired-in busy light before sending the string to the chip. Once the text has been send to the shield, it can begin building the next line of text. There hasn't been a problem with the delay settings although some adjustment might be needed in the future. The way it is setup, there is no easy way to change the voice settings. Again with the future, a way to set these parameters can be incorporated into the code. Copy the code into the Arduino IDE, make sure you have the SpeechSynthesis Library and upload the program. Hook up the RS232 port to the computer and try sending text through the Serial Monitor. Be sure to set the COM port to the proper number. /* DFROBOT Text to speech This program will read ascii text from a RS232 port, reformat it for the DFROBOT Speech Shield, and then send the string to the Shield for conversion to speech. */ #include <SoftwareSerial.h> #include <SpeechSynthesis.h> SoftwareSerial mySerial(5,6); // RX, TX byte ssr[500];//define a character string int busyPin = 5; byte whoToSpeak = 19;//voice number void setup() { mySerial.begin(9600);//baud rate computer Serial.begin(57600); // baud rate shield // say shield is ready, if you don't hear this something is wrong SpeechSynthesis.buf_init(ssr);//initialize the buff SpeechSynthesis.English(ssr,6,"shield test, testing shield, shield tested"); SpeechSynthesis.Espeaking(0,whoToSpeak,4,ssr);//Executive commands above, "0" is synthesis command; "19" select speaker; "4" speech function SpeechSynthesis.buf_init(ssr);//initialize the buff } int ReadLine(char str[]){ char c; int index = 0; while (true) { if (mySerial.available() >0){ c = mySerial.read(); if (c != '\n'){ str[index++] = c; } else { str[index] = '\0'; return index; } } } } void loop() { char txt[300]; int txtLength; txtLength = ReadLine(txt); SpeechSynthesis.English(ssr,6,txt); while(analogRead(busyPin) > 100){} delay(250);//wait for chip to be ready to receive SpeechSynthesis.Espeaking(0,whoToSpeak,4,ssr); delay(250);//wait for chip to show busy SpeechSynthesis.buf_init(ssr); } Hook the unit up to the 850 or P:R: Connection. I use a switch box wired to R2:. The cord is wired so that the pin outs at the box are the same as those of the IBM - USB to RS232 unit. The synthesizer is still a work in progress and expect to clean up the hardware before the next blog. Using a different port will require some changes to the program. The R2: is set up for block mode transmission of data, heavy translation mode and addition of a carriage return at the end of line. Of course the baud rate is 9600 to match the Arduino. Its that simple, once you know how. TYPETALK.BAS 100 DIM A$(200):GOSUB 30000 110 INPUT A$:PRINT #1,A$:XIO 32,#1,0,0,"R2:":GOTO 110 30000 CLOSE #1:OPEN #1,8,0,"R2:":XIO 36,#1,14,0,"R2:":XIO 38,#1,64,0,"R2:":RETURN RUN the program. The "?" is your sign to input some text. Hit Return and the text is sent to the R2: port in 32 byte blocks. The XIO 32 forces the transmission of the last few characters or short block. Then another "?". Ever wonder what Eliza would sound like with a Chinese accent? Me too.
  3. As a follow-up to another message thread I searched Amazon for RS232 equipped devices that could be hooked to the Atari through the 850 interface. A group of items were listed as RS232 to WIFI converters. I'm now wondering why I would want one of these? I'm thinking that there's not a lot of existing software for the converter so I'm really wondering what would it do if there was?
  4. Back in the day, I started writing Atari BASIC software to edit and transmit data to a Seiko RC-1000 Wrist Terminal Watch. This may have been the only time an Atari 8Bit, 850 interface, and RC-1000 were in the same room and if it happens again, you may want the following information to write a proper editor. The RC-1000s are being listed on eBay for around $250 to $2,500; I got mine while Seiko was liquidating their inventory at around $50. There were Apple, Comm.64, and IBM software versions and that truly made me feel left out as an Atari owner. I was hoping to get the software running and submit it to Seiko but it never caught on and the product line was dropped. Seiko was contacted for information that would help get the project started. They sent me a packet of pages containing the data structures, communication protocols and a printout of the IBM version of the software. These two documents are attached and will be of great help. Seiko RC-1000 Data Structurel.pdf Seiko RC-1000 IBM program doc.pdf I got the program to the point where it would read DATA statements entered with the proper format for text, time zone and alarm data. The computer would assemble the data and then dump it to the watch. The serial cable for the RS-232 connector required some modification for the 850 interface. I’m not sure which was the bigger problem; getting the data in the right format or configuring the serial connection. The following is the BASIC code example for the data structures. 400 DATA T WORLD TIME *401 REM -dccccccccccccTHHMM *410 DATA d DENVER CO 11000 *420 DATA d GLASGOW 00500 *430 DATA d MOSCOW 00700 *440 DATA d TOKYO 10200 *450 DATA d TAHITI 10700 *500 DATA L* PHONE ** NUMBERS *510 DATA dRITA 5551234WORK 5551234520 DATA dBRUCE5551234KAREN5551234530 DATA dNEIL 5551234JERRY *540 DATA dJEFF *590 DATA L* WORK ** NUMBERS *591 DATA dPAUL 3800DOLORIS 2077592 DATA dJOHN 2036SARAH 2203594 DATA dDAVE 2206MARK 2205595 DATA dRON 2984PAT 2204596 DATA dGEN LAB 2286JEFF 2014600 DATA L*CONVERSION** FACTOR *610 DATA d1M/39.37IN 1L/61.02 IN3620 DATA d453.6GM/1LB C=?F-32?*5/9630 DATA d 1LB/FT3 =16.018KG/M3 *640 DATA d 1G/CM3 =.03613LB/IN3650 DATA dDENSITY H2O 62.43LB/FT3660 DATA dVELOCITY SO.1088FT/SEC *680 DATA d1BTU=17.58W=.023HP=778FT690 DATA dLIGHT SPEED 2.997E8M/SEC700 DATA L* MESH ** SIZE *710 DATA d 15-1.19MM 20--850 *720 DATA d 30--600 40--425 *730 DATA d 50--297 100--150 *740 DATA d200-- 75 325-- 45 *900 DATA L* MIC. ** NUMBER *910 DATA d182-37-9329 71777-23 *920 DATA d6653-265-555-555 6/89 *930 DATA d7763 ****END*****2000 DATA S SCHEDULE ALARM *2001 REM -dccccccccccccMO/DD AHH:MM2020 DATA dWEDDING 03/03 A07:002030 DATA dWEDDING 08/03 A07:003000 DATA W WEEKLY ALARM *3001 REM -dccccccccccccD DAY AHH:MM3002 DATA dLUNCH TIME 1 MON A11:593003 DATA dBACK TO WORK1 MON P12:453004 DATA dTIME GO HOME1 MON P04:303007 DATA dLUNCH TIME 2 TUE A11:593008 DATA dTIME TO WORK2 TUE P01:003010 DATA dTIME GO HOME2 TUE P04:303015 DATA dLUNCH TIME 3 WED A11:593016 DATA dBACK TO WORK3 WED P12:453017 DATA dTIME GO HOME3 WED P04:303025 DATA dLUNCH TIME 4 THU A11:593026 DATA dBACK TO WORK4 THU P12:453030 DATA dTIME GO HOME4 THU P04:303032 DATA dTECH MEETING5 FRI A08:003035 DATA dLUNCH TIME 5 FRI A11:593036 DATA dBACK TO WORK5 FRI P12:453040 DATA dTIME GO HOME5 FRI P04:305000 REM END OF DATA An article was written for the Western New York Atari User Group newsletter that contains some information about data, cable modification, and the BASIC listing of the test software.Seiko RC-1000 WNYAUG article.PDF The watch had reached the end of its short lived product life cycle and the strap broke thus diminishing my drive to finish the project. But now with the success of the iWatch, Seiko may want to re-release the watch as a retro alternative (yah, sure), and you’ll have the information to write the interface program for your Atari computer.
  5. For quite some time I have been mulling over ways to improve character reception in a TI terminal emulator. Most terminal emulators combine the TI interrupt service routine and the RS232's circular interrupt buffer to receive characters. During character reception, the TI ROM ISR first determines if an external interrupt has occurred. If so, it must scan the peripheral cards one at a time to find the interrupt. Once the proper RS232 port is located, it must execute the card's interrupt service routine. The RS232's interrupt routine populates the 254 byte circular buffer that resides in VDP memory. Unfortunately, this whole process requires a lot of overhead and starts to fail miserably at speeds above 4800bps. Not only is the buffer size too small, all of the processing required to scan the card, handle the interrupt, and stuff it into VDP, require too much time. TIMXT could not exceed 4800bps successfully - at 9600, the TI spent 100% of its time servicing the interrupts, dropping characters along the way. Implementing hardware flow control was an option but it meant building a special cable that many people wouldn't care to make. I went through the same scenario with my Geneve terminal emulator: PORT can sustain 38.4kKbps without a special cable; it only requires handshaking when displaying color text mode (using the V9938 graphics mode and its slow character plotting) or when transferring files with Ymodem-G. But I digress. Months later I was looking at some information on Thierry's site when I came across an interesting article. It described an ingenious method to manage external interrupts using (abusing) the ROM interrupt service routine: http://www.unige.ch/medecine/nouspikel/ti99/jeff.txt This idea resonated with me. In PORT, I hijacked the system's interrupt vectors so that I could process external interrupts, video, and keyboard with no system overhead. This was "easy" to do with an OS in RAM. But the TI ROM is..well..ROM! I was skeptical at first; will there be much of an improvement? It took me a day or so to modify the emulator. I reserved a 4K buffer to stash incoming data. Two routines are required: an interrupt-driven RS232 capture routine and a buffer emptying routine. Think of the buffer like a bucket: one routine fills the bucket with characters; the other routine draws them out for display and other purposes. Only the active RS232 is checked and it is given immediate priority in the user ISR. Once complete I did some base testing with my Geneve. I then asked Omega to test the program at 9600bps. He reported success. He then told me he used 19.2 with success! So, I added an option for 38.4K and surprisingly, it worked! With no hardware handshaking or cable magic! There are a few considerations: 1. Some peripherals rely upon GPLWS R15. Jeff's method changes this value, so disk and other peripherals may fail. My solution was to modify DSRLNK to turn off RS232 interrupts and restore R15 prior to calling the ROM routine. The environment is restored afterwards. 2. All VDP-based automatic processing is inhibited. No sound, no quit key, no 50/60hz timers. You can enable the VDP interrupts and service them if you restore things to 'normal', and then re-enable the interrupt handler when complete. You cannot have both operating at the same time. I suppose a 9901-based 60hz timer may work, I'll have to try that some day. 3. Keyboard scanning takes a long time. For time-sensitive RS232 input, I use a modified direct keyboard scanning routine that can be interrupted in between steps. My next challenges are to improve the keyscan routine and optimize the display interpreter. Later a uni-directional flow control may be needed especially when there is so much data being displayed so quickly.
  6. Hello 99ers I have been toying with the idea of playing with my favorite micro (1 quess only )but have only RS232 sidecar and the Assembler module. I noticed that the RS232 guide suggested "Exchanging programmes with SAVE and OLD" I am assuming that this would be a memory image dump so I could save and recover it as a file on the ole PC. Does any one know if this will work or has even tried it? Thanks in anticipation
  7. I am searching the Hex-Bus RS232 device. Anyone willing to sell his to me? We can also trade TI stuff. I need it to get the soon to arrive TI-99/8 interacting with Web99.
  8. Getting the DFRobot voice synthesis shield working was an interim project until I could justify the procurement of a Wizztronics MidiMax unit. Now that it is here I want to get the last experiments documented, in case I ever want to turn the shield into a MIDI device. The last modification to the type and talk program added the ability to re-transmit the last words typed, if just hit the return. The program is still 3 lines of BASIC. 100 DIM A$(200),B$(200):CLOSE #1:OPEN #1,8,0,"R2:":XIO 36,#1,14,0,"R2:":XIO 38,#1,64,0,"R2:" 110 INPUT A$:IF LEN(A$)>0 THEN B$=A$ 120 PRINT #1,B$:XIO 32,#1,0,0,"R2:":GOTO 110 I got the Arduino and TTL to RS232 converter mounted onto a display plaque. Now the shield can be removed so the rest can be repurposed for another setup. They do get used a lot for my Atari8 projects. The next problem showed up when I wanted to record the voice. The headphones were unplugged and the computer aux. input was hooked up. A 60 cycle hum was now present where it wasn't before. I went back and listened to some old recordings and it was there, just not as loud. Turns out that that the shield uses a 4 connector 1/8" audio plug and the computer has a 3 connector plug. I opened up the drawer with the capacitors, closed my eyes, and picked out a 33 micro Farad, 50V capacitor and soldered the "+" side to ground on the plug and inserted the "-" into the ground pin of the Arduino. I'm not to sure of my method but the hum went away. The voice does seemed to be a little less harsh to the my ears (to me that's a good thing). Soldering the wire to the busy light probably voided the warranty so making this connection can't make it any more voided. Just before the MIDIMAX arrived I started working on adding speech to the old BASIC text "Adventure" game. There were at least 50 lines with PRINT statements and each one had to be examined to determine if the text should go to the screen or the RS-233 port. I got it to the point where it would speak the intro and then half way through the place description, it would cut to the next packet of information. There was a timing problem that needed to be solved. I think maybe using the block mode of transmission may not have been the best choice. The 32bit buffer may have been getting overwritten or maybe something needed to be changed on the Arduino side. Then the MIDIMAX arrived. Here are some sound samples from the "type and talk" program. The Arduino had to be reprogramed to get the different voices. They claim 19 different voices but most of them sound much the same to me. Voice examples.zip Like I have said, I didn't do any research on hardware alternatives. I can't say this is the best or most cost effective Text-to-speech hardware available. Would I go out and buy it again? Probably not, but I've had some fun playing with this one. P.S. I wish I hadn't thought of turning this Voice Shield into a MIDI device. I have the hardware; an Arduino, MIDI input (and a through port would be nice), switches to change parameters(and you can do this through midi commands) and a text display to view parameter settings. Maybe designing the MIDI Implementation Chart would be the best place to start. Channel #, using note numbers for predefined phrases, program changes for voice types, change speed with the pitch bender.. Whatever it would become, it would be playable using MIDI port hooked up to the Atari8. (or other MIDI equipped computer)
  • Create New...