Jump to content

Search the Community

Showing results for tags 'Arduino'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • 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
  • 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
  • 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


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
  • ZeroPage Homebrew's Schedule

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 11 results

  1. Drum Synth/Bass Synth by Glen Gutierrez are 2 programs featured in the Antic Feb. 1985 issue. Antic Editor: "These are the most realistic instrument simulations we've ever heard at Antic." The Drum Synth program has been MIDIfied to except data from an Arduino+MIDI shield through the joystick port. Now the drums can be beat from a MIDI keyboard(MKB) or sequencer. Software: The chart follows the data from the MIDI NOTE ON source to the Atari Computer running the Drum program. The general MIDI LEVEL 1 Percussion key map was used to maintain some continuity between different midi instruments. <https://www.midi.org/specifications/item/gm-level-1-sound-set> The drum hit starts at the MKB. Press the key for the drum sound you want. This sends a MIDI NOTE ON message byte to the Arduino. The Arduino has been checking the data stream from the MKB to find a NOTE ON command for a specific MIDI Channel(channel 1 in this case). When it detects that byte it reads the next two bytes, the note number and then the velocity. If the velocity is above 0, the note number is used to set the patterns for the joystick port input. Any note number not mapped to a drum sound in the computer is ignored and the Arduino looks for the next NOTE ON+channel message. When the Joystick pins has been set, the trigger is set to tell the computer to read the joystick port. A short delay is used to give the computer a chance to read the port before it is reset. The computer has been sitting there waiting for the trigger to change state. If it changes while a percussion sound is being made, it POPs out of the FOR-NEXT Loop turns off the sounds and returns to the input loop. The input loop is where the computer reads the joystick pins and looks for a number between 1 and 12. This number is used as an index into an array(JTOK()) containing the original computer key codes mapped to the sound routines. The key codes are then used as an index into an array that contains the subroutine line numbers for the different percussion sounds; a hold over from the original program. Hardware: A MIDI shield for Arduino can be purchased for less then the cost to build one. It might be a good idea to get one that has a MIDI THRU port. It gives you the option of adding additional synthesizers to your MIDI setup. The Arduino-to-Joystick circuit is the same for the Drum-MIDI interface and the Wii-Nunchuk interface. Don't hook up the Nunchuk and plug in a midi shield. Digital pin assignments are a little different and are listed below. The MIDI shield connects to D0 and D1 for serial communication with the MIDI source. I still like using optocouplers to isolate the Arduino and computer whenever I can. NUNCHUK + ARDUINO = ATARI JOYSTICK From <http://atariage.com/forums/blog/572/entry-11529-nunchuk-arduino-atari-joystick/> The pin assignments for this project are as follows: Arduino Optocoupler # Joystick pin D4 1 1 D5 2 2 D6 3 3 D7 4 4 D3 5 6(trig) 8 GND for Atari side of optocoupler Pin assignments can be changed as long as the Arduino sketch is modified to match. The ZIP File Contains midi_drum_02 - Arduino sketch folder. SYNDRUM3.ATR - single density format DOS.SYS,DUP.SYS - DOS 2.5 SYNDRUM.BAS - original program from Antic SYNDRUM3.BAS - MIDIfied Program to use with Arduino interface SYNDRUM3.BTX - LISTED BASIC code SYNDRUM3.zip I was going to record the drums. Running the original program will get you the same sound by pressing the keyboard keys. I'll make the recording when I get some drum patterns programed into MMS. Send the midi data through the MIDIMax to a second computer with an Arduino-MIDI shield interface(channel 10). Then daisy-chain a third computer with interface(channel 11) through the THRU port. Run the audio outputs to a mixer and record, maybe adding some FX. That's after I find way to remove the unwanted low level hiss coming out of the Atari. P.S. This is not a MIDIjoy unit. Although I did take some inspiration from its makers. I am going to make one, someday.
  2. There is a sound recording of the first attempt to simulate wind chimes within the following .ZIP file. It was recorded using Window 10's Voice Recorder. The A8 used Atari BASIC's RND(0) function to pick note, volume, and delay values for the chime strikes. Then sent the MIDI data to the Yamaha TG33 Tone Generator, Preset 2 #87 PC*Bells. You don't need the A8 setup to hear the recording. Its in .m4a format. A8 Wind Chimes - Gentle Breeze in C minor.zip If you are interested in the A8 side of this, read on. The idea was/is to simulate wind chimes by programming an A8 to output MIDI data to the tone generator. The 850-Arduino-Midi connection has been described in previous blog entries. The first thing that needed to be accomplished was to decide which Midi notes to assign to the six chimes. Information on how to build your own chimes was found on Michigan Technological University's site. It had suggestions on how to choose the notes. One was to pick the notes and then play them as randomly as possible on the keyboard. http://www.phy.mtu.edu/~suits/windchime.html The other was to setup a pentatonic scale used to make most of the tuned chimes. The major and minor keys are explained at: http://www.phy.mtu.edu/~suits/pentatonic.html These links provided enough information to start programing the chimes. Once the MIDI Note values have been chosen, the program chooses a random note, and random volume and some random delay between notes. It took some experimenting to get the program to start to sound like wind chimes. BASIC made this really easy. Change the parameters, enter RUN, then press reset to stop the program. I could have done this all day; and perhaps I did. 1 REM WIND CHIMES USING ARDUINO MIDI OUTPUT. 2 REM PACK007 - 9/29/2016 3 REM First experiment to determine MIDI Note vales, random timing values, and volume values for chime simulation 10 GOSUB 30000:REM SET UP RS232 PORT 20 DIM TONE(6):CMD=144 30 TONE(1)=60:REM NOTE C4 40 TONE(2)=TONE(1)+3 50 TONE(3)=TONE(2)+2 60 TONE(4)=TONE(3)+2 70 TONE(5)=TONE(4)+3 80 TONE(6)=TONE(5)+2 100 MIDINOTE=TONE(INT(RND(0)*6)+1) 110 VOL=INT(RND(0)*60)+20 120 DELAY=INT(RND(0)*500) 200 PUT #1,CMD:PUT #1,MIDINOTE:PUT #1,VOL 210 ? MIDINOTE,VOL,DELAY 220 FOR X=1 TO DELAY:NEXT X 230 GOTO 100 29999 REM SETUP RS232 PORT FOR CONCURRENT OUTPUT TO ARDUINO-MIDI 30000 CLOSE #1:OPEN #1,9,0,"R2:":XIO 36,#1,14,0,"R2:":XIO 38,#1,32,0,"R2:":XIO 40,#1,0,0,"R2:":RETURN Making changes to the program can be fun but now a program needs to be developed to adjust the variables to simulate any atmospheric condition, during program execution.
  3. While playing Pac-man with a standard Atari Joystick, how often have you missed a turn? I may have a solution, if its due to pushing the joystick to far off the four directional axis. If its due to a slow reaction time then you're still on your own. I noted while playing Pac-man that my granddaughter would rotate the joystick base and start pushing the joystick into the diagonal directions(and so was I to a lesser extent). When 2 directional buttons on the joystick are pressed Pac-man determines that you are not sure which way you want him to go and continues to the end the lane. An Arduino can be used to read a Wii nunchuk analog joystick and determine which of the 4 directions it is closest to and then set the joystick pins. This would double the acceptable error from true UP, DOWN, LEFT and RIGHT. I believe it has improved my Pac-man scores. The first time I used the setup I was able to advance to level 2. The second try got me to level 3. The third game got me to level three with a personal high score of 12,200 points. I'm getting the feeling that I'm RTC (Reaction Time Challenged)? What to do? My first Out of the Pack blog project was using the nunchuk as an Atari Joystick. The circuit hasn't changed much and is still using the same Arduino library from a slightly modified program from "Arduino: A Quick-Start Guide" by Maik Schmidt. You'll need some of this information. http://atariage.com/forums/blog/572/entry-11529-nunchuk-arduino-atari-joystick/ The prototype shield built for the Synthdrum project was reused. This shield has been getting a lot of use . A reset button has been added since the last time it was photographed. You can even leave the MIDI shield plugged on the stack but be sure to turn it off. http://atariage.com/forums/blog/572/entry-13921-midi-music-system-and-two-synth-drums/ The Arduino program is simple enough. Of course, I could have saved myself a couple of days of frustration if I had paid closer attention in trigonometry class. I can still remember 45 years ago saying to myself, "When am I ever going to use this crap." I suppose that it would have been easier to download the MATH library with the required functions to calculate angles but I found a way……. 1. Read the nunchuk x,y 2. Adjust x,y to 0,0 point of origin. 3. Calculate the Radius of a circle through adjusted x,y (a^2=b^2+c^2) 4. Use SIN,COS table to calculate XY limit points at the 45deg limits 5. Determine which limit points the XY is between. 6. Set the joystick port 7. Check the button status 8. Start over. atari_nunchuk_4_Pacman.zip Most of the testing was done with the unit plugged into the ATARI8 and using the following program. 10 X=STRIG(0):Y=15-STICK(0) 20 IF X<>LASTX OR Y<> LASTY THEN ? X,Y 30 LASTX=X:LASTY=Y 40 GOTO 10 Then I remembered that I had made the Joystick Tester for just this situation and that worked too. http://atariage.com/forums/blog/572/entry-11972-pocket-joystick-tester/
  4. k-Pack


    I've added a third computer to the MIDI chain. Computer #1 plays drums, and Computer #2 runs S.A.M. and Computer #3 plays the lead, . Each computer had a specific BASIC program written to read data from the joystick ports. For this example, Queen's -" We Will Rock You" was arranged for the three computers. You can listen to the MP3 file and then decide if you want to read about the how. SAM Rocks - mp3.zip COMPUTER #0 - Control The music was entered using the MIDI MUSIC SYSTEM software. Voice 1 - Lead was assigned to MIDI channel 1, Voice 2 - SAM assigned to MIDI channel 3, and Voice 3 - Drums is Channel 10. All the editing was done using the CASIO-481 keyboard. Once the playback was acceptable, the rest of the computers were programed in BASIC and the Arduino interfaces were built. COMPUTER #1 - MIDI Channel 10 - Drums The same drum setup from the last two blog entries was used. Only one computer was required for this simple drum pattern. Computer #2 - MIDI Channel 3 - S.A.M. Getting SAM to sing the words was accomplished by activating the trigger button at the right time. The Arduino would read the MIDI data stream. Whenever a 146(NOTEON+2) command was received by the Arduino the joystick state was changed to zero for 10 milliseconds. When the Atari program detected the joystick status change, the next word is sung. Before the Atari was programmed the phoneme spelling of the words were created using the SAM Word Editor(another previous blog entry). Then a small test program was used to change the speed and pitch of the voices to meet the requirements of the music. The BASIC program simply reads the joystick port and when it reads 0 the next word is sung. This created a problem. If SAM was speaking it couldn't detect that the next word needed to be sung and resulting in skipped words. This problem was finally solved by changing the TEMPO in MMS from 175 to 160. Computer #3 - MIDI Channel 1 - Lead If I had started the work on the this computer, the project may never have been finished. Since the work on SAM was done I had to continue on. Bad solder joints, program logic and a misunderstanding of the MIDI data from the Casio or MMS added to the confusion. This was the first time a full 8bits were required to be received by the Atari8(A8). Four additional optoisolators were added to the Arduino Uno. This way the Atari could look for the MIDI command number for NOTEON or NOTEOFF. When NOTEON was detected at PORTA(joystick address) the computer would wait till the note number was set and the joystick trigger logic state changed. The note number was then used to calculate the index for an array holding frequency settings. The Arduino did most of the work decoding the midi data. You would almost think that a NOTEON would be followed by the NOTEOFF command before the next NOTEON command. NOTSO, when the Casio Keyboard was being used to test the hardware and software. Eventually the Casio was hooked up to the IBM running a MIDI Monitor. Press a note key and a NOTEON command was sent. Release the key and a NOTEON command was sent. The only difference was the velocity setting. Setting a NOTEON at 0 velocity does stop the note from being heard. You would almost think that a NOTEON would be followed by the NOTEOFF command before the next NOTEON command. NOTSO, when MMS was used to create the MIDI data stream. Some times the NOTEON command was issued before the last note turned on was turned off. So, the NOTEOFF command received by the Arduino was sent to the Atari only if the note matched the last note turned on. A function to set the output pins on the Arduino was used instead of the "case" used in the drum software. Each bit of the note byte is checked starting at bit 0. When the 7th bit is turned on the A8 computer knows it is a command byte that starts the process of turning on or off a note. The A8 then waits for the joystick trigger button to change state to indicate the note number is ready to be read. delay()s are used to give the A8 enough time to check the PORTA and the trigger. Project Software The ATRs and Arduino source code are in the zip file. The computers in the midi chain have no monitor so the programs for the drums and lead will autorun the BASIC programs. SAM would not allow the autorun code to execute the BASIC program when appended onto end of the AUTORUN.SYS file, so an easy name of "A" was used to reduce typing required to RUN "D:A". The Arduino source code for each of the instruments are in the folder. Also, an ATR containing the MMS music and info files is included. SAM Rocks - support files.zip That should be enough information if I ever want to rebuild this setup. Its been nice to be able to write custom programs and build Arduino interfaces for each voice but I have to start thinking about…. 1. A polyphonic A8 program for general use. 2. Two way communication between the Arduino and A8 3. Using commands beyond NOTEON and NOTEOFF 4. Programming using MAC/65 5. An editor for SAM to include pitch and speed manipulation 6. Getting a new furnace before winter sets in.
  5. I finally put together a semi-live performance using the DH-100 Digital Horn to control the sound of an Atari XE computer. I know that improvements to the hardware/software is not going to improve my ability to play the horn but there is much that can be done to improve the sound. There were some changes made to the last Atari program. First, the second hi-res voice was added and an off-set. This was to see how much of an effect the phase shift would have on the combined frequencies. In places you might be able to hear this beating effect, when the notes are of sufficient duration. Second, I removed the print statements, turned off the screen and recompiled the BASIC program. This improved the data collection and processing speed to the point where the portomento loops had to be modified. I did find another glitch in the DH-100 data stream. When you turn off the horn, a patch change is sent through the MIDI channel. This was a pain when the screen was turned off. Oh, Well… I said semi-live because the BAND IN A BOX contribution was recorded once. Drums, keyboard, and tuba sounds don't sound to bad. Then I recorded myself playing the DH-100 on several tracks and pasted the usable sections together. I left some mistakes in just so you know that the DH-100 wasn't computer controlled. Don't worry, I didn't give up my day job to become a performer. This is the seventh blog entry for the DH-100. It seemed like a long process and there is enough information if you are in need of such information. I think I'm done playing with the DH-100 but will be looking into improving data flow using the Cassette Motor Control link and look into Fritzing an Arduino shield for the optocoupled joystick connections.
  6. Do you remember me mentioning that the first attempt to write a machine language program to read MIDI data delivered to the Atari joystick port was a complete failure? The Arduino hardware has remained the same. The joystick trigger and cassette motor control(CMC) pin on the SIO port are still being used to control data flow. But this time I redefined the project specs to simplify the ML program and tested the ML data transfer routine as a USR call. The USR routine was written to replace the BASIC code that checked the joystick trigger to see if data is ready to be read, gets the data, and tells the Arduino to get the next byte by setting the CMC. (the subroutine starting at line 100 in many of the earlier programs) The data byte is stored in a page Zero location to be PEEKed after control is returned to BASIC. Once working as a USR call the PLA was removed and the M65 file was edited and saved for later inclusion in the Project file as a subroutine. #INCLUDEd READMIDI.M65 routine is as follows: READMIDI.M65 01 ;USR FUNCTION TO GET MIDI DATA FROM02 ;ARDUINO BOARD WITH DATA FLOW CNTRL03 ;DATA RETURNED IN LOCATION $CB04 ;05 ;Kevin Packard 4/201906 ;0100 ;STRIG0 = $0284 -ARDUINO DSR0110 ;PORTA = $D300 -JOYSTICK INPUT0120 ;PACTL = $D302 -SIGNIAL ARDUINO0130 ;0140 READMIDI0150 MU1 LDA $0284 ;STRIG00160 CMP #00170 BEQ MU1 ;WAIT FOR DATA0180 LDA $D300 ;PORTA-READ DATA0190 STA $CB ;STORE BYTE PEEK(203)0200 LDA #52 ;DATA READ0210 STA $D302 ;PACTL-CMC ON0220 MU2 LDA $0284 ;STRIG00230 CMP #10240 BEQ MU2 ;LOOP TILL RESET0250 LDA #60 ;TURNS OFF BYTE0260 STA $D302 ;PACTL - CMC OFF0270 RTS ;RETURN Playing a MIDI note on the monophonic-Atari in its simplest form consists of receiving the MIDI note number for the tone to play or to turn the tone off . If you assume the volume value to be the same for every note then the volume data doesn't have to be sent. Since a MIDI note can have a value of 0 - 127, passing a value of 128 can be used to signal note off. The Arduino had to be reprogramed to minimize the data being sent to the Atari. The Arduino will first look for MIDI data for channel one. If its a NOTEON or NOTEOFF command it reads the following MIDI note number and then the volume byte. It then makes the decision to send a note number to start or change the pitch OR turn off the note being played. The logic makes sense considering a NOTEOFF command can be transmitted for a note that isn't being played or a NOTEON can set the volume to ZERO. /*Mono synth - channel 1 * Sends: * MIDI Note number to play * or * Bit 7 ON(128) to turn off note * * Kevin Packard May 2019 */// Atari PORTA(54016) mapped to pins on arduinoint porta0 = 4;int porta1 = 5;int porta2 = 6;int porta3 = 7;int porta4 = 8;int porta5 = 9;int porta6 = 10;int porta7 = 11;int DSR = 3; //data set ready triggerint DTR = 13;//Atari ready cmc byte zero = 0;byte midiData = 0;byte midiCommand = 0;byte midiNoteNum = 0;byte lastMidiNoteNum = 0;byte volume = 0;byte volOff = 128; //Function to Send a byte to the Atarivoid sendByte(byte byteToSend){ setPorta(byteToSend); digitalWrite(DSR,LOW); //data ready-Trigger 0 while(digitalRead(DTR) == LOW){} //Wait for Atari to get byte cmc goes low digitalWrite(DSR,HIGH); //data not ready-trigger 1 while(digitalRead(DTR) == HIGH){} //wait for Atari to signal ok to get next byte} void setPorta(byte byteToMap){ // Sets digital pins to transfer data to Atari joystick ports(PORTA) // When digital port high, joystick pin shorted to ground or logic 0 if (byteToMap & B00000001){digitalWrite(porta0,LOW);} else {digitalWrite(porta0,HIGH);} if (byteToMap & B00000010){digitalWrite(porta1,LOW);} else {digitalWrite(porta1,HIGH);} if (byteToMap & B00000100){digitalWrite(porta2,LOW);} else {digitalWrite(porta2,HIGH);} if (byteToMap & B00001000){digitalWrite(porta3,LOW);} else {digitalWrite(porta3,HIGH);} if (byteToMap & B00010000){digitalWrite(porta4,LOW);} else {digitalWrite(porta4,HIGH);} if (byteToMap & B00100000){digitalWrite(porta5,LOW);} else {digitalWrite(porta5,HIGH);} if (byteToMap & B01000000){digitalWrite(porta6,LOW);} else {digitalWrite(porta6,HIGH);} if (byteToMap & B10000000){digitalWrite(porta7,LOW);} else {digitalWrite(porta7,HIGH);}} void setup() { pinMode(porta0,OUTPUT); pinMode(porta1,OUTPUT); pinMode(porta2,OUTPUT); pinMode(porta3,OUTPUT); pinMode(porta4,OUTPUT); pinMode(porta5,OUTPUT); pinMode(porta6,OUTPUT); pinMode(porta7,OUTPUT); pinMode(DSR,OUTPUT); pinMode(DTR,INPUT); Serial.begin(31250); setPorta(zero);// digitalWrite(DSR,HIGH);} void loop() { //read data until its a Midi command //command bytes will have bit 7 true while (midiCommand != 128 && midiCommand != 144){ //midi command + Channel while(Serial.available()<1){}//wait for data midiCommand = Serial.read(); //read MIDI stream } // get data required by command. while(Serial.available()<1){} midiNoteNum = Serial.read(); while(Serial.available()<1){} volume = Serial.read(); if(midiNoteNum == lastMidiNoteNum && ((midiCommand == 128) || (midiCommand == 144 && volume == 0))){ sendByte(volOff); lastMidiNoteNum = 0; } if(midiCommand == 144 && volume > 0 && midiNoteNum != lastMidiNoteNum){ sendByte(midiNoteNum); lastMidiNoteNum = midiNoteNum; } midiCommand = 0;} // End of Listing The Atari now simply has to wait for the Arduino to set the trigger as new data is ready to be received. It then will turn off the sound, turn on the note, or change the pitch. The response time seems to be much faster then the compiled BASIC program. The Arduino"s data buffer didn't get overwritten when I ran my fingers up and down the keyboard or mashed down a bunch of keys over and over. I did note a bit of a delay as the buffer emptied. SINGBYTE.M65 0100 ;MIDI SYNTH MONO VOICE0110 ;ARDUINO 8BIT INPUT/CMC CONTROL0120 ; Monosyn_1-Byte_Data.ino0130 ;K-PACK 20190140 ;0150 STRIG0 = $02840160 AUDCTL = $D208 ;SET TO 120 - 16BIT FREQUENCEY DEFINITIONS0170 AUDF1 = $D200 ;LOWBIT- VOICE 10180 AUDF2 = $D202 ;HIBIT - VOICE 10190 AUDC2 = $D203 ;VEL-DIS-VOICE 10200 AUDF3 = $D204 ;LOWBIT- VOICE 20210 AUDF4 = $D206 ;HIBIT - VOICE 20220 AUDC4 = $D207 ;VEL-DIS-VOICE20230 SKCTL = $D20F0240 PORTA = $D300 ;JOYSTICKS VALUE0250 PACTL = $D302 ;CMC 60-OFF 52-ON0260 CMCON = 520270 CMCOFF = 600280 MIDIBYTE = $CB0290 ;0300 *= $40000310 .INCLUDE #D:FREQTABL.M650320 .INCLUDE #D:READMIDI.M650330 ;0340 ;0350 ;0360 START0370 LDA #0 ;RESET AUDIO0380 STA AUDCTL0390 LDA #30400 STA SKCTL0410 LDA #1200420 STA AUDCTL ;SET 16 BIT SOUND0430 LDA #CMCOFF0440 STA PACTL ;SET CASS MOTOR0442 LDA #00444 STA $022F ;kill SCREEN0450 ;MAIN LOOP0460 JP1 JSR READMIDI0470 LDA MIDIBYTE0490 CMP #128 ;NOTE OFF?0500 BNE JP20502 LDX #00505 STX AUDC20520 JMP JP1 ;GET NEXT DATA0530 JP2 LDX MIDIBYTE ;OFFSET FREQ TABLE0540 LDA FREQLO,X ;SET FREQ0550 STA AUDF10560 LDA FREQHI,X0570 STA AUDF20590 LDX #173 ;DIS=10 VOL=130600 STX AUDC2 ;TURN SET VOL0610 JMP JP1 ;NEXT COMMAND BYTE0620 ;0630 *= $02E20640 .WORD START0650 .END I'm hoping this program will be a good start for some interesting routines to modulate the sounds. A sound recording didn't seem to be necessary and the Arduino interface has been explained in previous blog entries. The atr file contains the MAC/65 files and BASIC files used to create and test the USR input routine. mls01.atr
  7. The more you play around with Arduino circuits for your Atari8 the more likely it is that you will be soldering stackable header pins onto prototype boards. The better the solder job, the easier it is to stack your boards. No mater how many times I try I haven't seen an improvement in my skill set. At lease not until I built this LEGO fixture to hold the pins perpendicular to the board while soldering. The fixture uses LEGO Technic parts. They are all standard parts. Attached is the build instructions made using LEGO Digital Designer(LDD) software. LDD produces an HTML file with a folder of supporting files. I tried using Microsoft Edge to display the page but was unable to view it. Internet Explorer displayed the instructions and parts list. You will need two rubber bands to complete the build. Instructions:Building Instructions Arduino Header Fixture-images.zip Make sure the pins are seated along the side beam. The photos show the pins in place, with and without the PCB. I noted that it is easier to place the pins in the board before mounting them in the fixture. Just one minor suggestion. If you notice your melding the LEGO parts, you may want to consider getting a lower wattage soldering Iron.
  8. k-Pack

    RTC v2.1

    I wanted the RTC project to be over but it wasn't long before daylight savings kicked in and I needed to reset the clock. All I wanted to do was be able to run a program on the Atari8 to set the time on the RTC and then have it rerun the SETCLOCK.BAS to update the clock on the Atari8. And as long as I was going to do that I may as well reconfigure the hardware and………. . So by the time I was finished it needed to be called version 2.1. Hardware: When I found Arduino Uno clones for $6.50 it didn't seem cost effective to build my own PCB. Then the price of the bare Sparkfun prototype shield seemed reasonable so I used one of those. The parts list for the shield: Prototype shield and pins RTC module RS232 to TTL converter module Set CLOCK push button 10K Resister LED 330 ohm Resister Micro switch for Arduino reset on shield. (not required, you can hold down set button and turn power off and on) The schematic shows the pin usage and wiring. How you place your components may be different. There is more then one design of prototype shields and components. This time the power for the RTC module is supplied by Analog pin 2 and 3. The pins were set for output and pin 2 was set to Low(ground) and pin3 was set to HIGH(+5V). The RS232 converter is wired to digital pin10 and 11. This allowed the USB serial on pin D0 and D1 to be used for programming and power. The softwareSerial library was used to send and receive data to the Atari8. (This also created the option of using both USB and RS232 ports at a later date.) The set time button is used to activate the routine to receive RTC data from the Atari8. Press the button then power up the unit or press the reset button. The LED should turn on, indicating that the Arduino is ready to receive the data from SETRTC.BAS program. SOFTWARE: The arduino sketch and atr disk image are contained in the .zip file. RTC_v2_1.zip Of course the Arduino software was rewritten. Version 2.0 tested the softwareSerial library. (http://www.arduino.cc/en/Reference/SoftwareSerial) Once that was working the set RTC function was implemented and called v2.1. (I know someone is going to want to know what happened to version 2.0. ) The SETCLOCK.BAS program is still the same program as before and is run by the same AUTORUN.SYS file. The SETRTC.BAS is new. Once the Clock is running and you want to reset the time on RTC; run this program. It sets up the 850 for serial output then gathers the time/date information. Although the Atari Clock uses only the time data, the RTC needs the date data to reset.(who knows, some day you may need the date.) There is no AM/PM option; time will need to be military time. The computer then waits for you to put the Arduino in set time mode. Press the button and then press the reset button. When the LED lights the Arduino is ready to accept the data. Press RETURN on the Atari. The Atari8 then sends the data to the RTC and runs SETCLOCK.BAS to resets the ATARI clock with the new time. Can it be any simpler? Since I expect this to be a one of a kind project. Feel free to use this as reference or modify it to suit your needs. Even if you're trying to use it with your RS232 equipped C64.
  9. We all remember some DOS-era computers that had a light that flickered with levels of CPU activity, disk activity, etc. I wonder what the technical possibility would be to have a kind of "LED shell" that could do something similar for the Intellivision? I'm thinking of a kind of cartridge shell with maybe an Arduino trinket and a watch battery inside, some kind of attachment (wire?) that would attach on one of cartridge address lines, with a LED or two mounted on top. Then open up an existing cart, place it in the "LED shell" and during play it would light up in certain conditions. This isn't about commercial feasibility, just the tech and development angle... Would it be possible? I would love to have extra Christmas Lights on my Christmas Carol game!
  10. This was a very cheap thing to hack together: the C64 was almost free from a garage sale, and I used an $8 Arduino Pro Micro from Aliexpress. I've seen people connect an Arduino directly to the keyboard output, but I wanted to try something using the user port, as it's a very cool feature of the C64. Also I don't have any way to load or save data on the C64 at the moment, so there wasn't much else I could do with it! (the first project probably should have been a tape adapter...) Hardware-wise, I shared the USB and 5v C64 user port power, and connected the user port data lines from to 8 of the Arduino's pins, configured as digital inputs. The Pro Micro can act as a USB keyboard (so that bit's easy), so all I had to do was 1) Write a 2 line BASIC program (As short as possible as I have to retype it on power on) that dumps a byte to the user port alternately for the currently pressed key and current modifiers (Ctr/Shift/C=), and 2) Convert the 8 data inputs back into a byte in the Arduino, work out the corresponding key pressed, and send it to the USB keyboard. Seemed responsive enough for any lag to be not really noticeable, but I'd like to give it a more thorough test. IThe data could be pushed to the user port quicker by an assembler loop, which would probably decrease the lag. Connecting to the C64 was a bit Heath Robinson, as I don't have a proper user port edge connector and it's quite fiddly to build one. if I can construct a better edge connector or find a proper one I'll finish it off and take some photos. Of course, configurable keys, macros, key combinations for nonexistent keys etc. would all be pretty easy to do in software on the Arduino.
  11. I started talking about this over in the TK-II thread and thought it best to create its own thread. So my thinking is to possibly create an ICSP (In Circuit Serial Programmer) for a specific PIC micro controller chip made by Microchip, and using the Atari 8 as the actual programmer to re-flash the PIC device. So to see what is involved check out this diagram (courtesy: www.learningaboutelectronics.com). So imagine if you will that what is shown as the PIC Programmer, would be interfaced to the joystick port on the Atari 8, with one exception, that being a means of generating the higher Vpp voltage to initiate programming mode. For the specific PIC I have in mind (PIC16F1847), Vpp would need to be 9 VDC (older PICs require 13 VDC). There are Charge Pump IC's that'll double the 5 V available at the Joystick port, and Maxim is one of the manufacturers of just such a device (MAX1682/1683). These are good for about 98% conversion efficiency so the output should yield about 9.75 VDC. If that output is then switched by a transistor via a joystick I/O pin, that should bring us very close to 9 V factoring in the semiconductor losses of the switching transistor (example below). Besides this little bit of circuitry, everything else can be a direct connect to the joystick pins, thus keeping the hardware end of this project ultra simple (substitute a 9 V battery for the charge pump and it gets even simpler). So it appears that the hardware requirements are rather easily met, what about the ICSP programming (flashing) software? Well the nice thing is that the HEX files generated by most all of the PIC compilers is an ASCII coded file, and it contains all of the parameters required by the chip, including what are called configuration bit or fuse settings. At this time I don't totally understand the protocol requirements when sending this data to the PIC chip, but when I dive into this project later, hopefully I wont find it too difficult to understand for implementation from the Atari point of view. Some Reference Material: Microchip In Circuit Serial Programming Guide Microchip PIC16F1847 Memory Programming Specification - Michael
  • Create New...