manterola

It also helps to know where you are located. It might be a friendly Atari enthusiast closer that can help you finding the problem with your 600xl.

Similar situation in Chile. We grew up around pirated cassettes that were sold in the mainstream retailer stores, or copies of those done using those dual cassette boomboxes. The only cartridge I knew in the early years (before XE era) was a Star Raiders cart that a friend of mine had, and that's it. I bet it was the same in many parts of the world. Example:

Yep everything that is not zero will execute the command

My first submission to HSC, ever. PAL system in the default skill level. Regards!

In XLs there is a circuit to produce 9.5v or similar for the cadj circuit using what is called a charge pump with Phi1. Probably XEs have similar circuit. My guess is that there a capacitor of that circuit not working properly, so the circuit is producing an unstable voltage. Check the posted thread, and also the circuit schematics and check if the voltaje changes, and if those changes correlate with the changes in colors you see in the screen.

The Bluetooth option is a very decent substitute to the tnfs server for android. However, the Bluetooth emulation never worked for me. Not using your short program for the esp32, nor using the latest firmware and pressing Boot. It it detected by sio2bt app in android, I can do the pairing and the connection. So everything looks great up to that point: it shows connected and I selected the images. But then nothing happens if I try to boot an image or read a directory (only Atari farts). Not sure what is wrong since your small program it is quite simple. Maybe there is an option I did not selected in the Arduino IDE... BTW the same phone with sio2bt app works perfectly with the original SIO2BT modules.

Great news! congrats!. For the keyboard, maybe it just need some cleaning. If not and if your keyboard is a type 4 stackpole you can get new mylar from here:

I was thinking that maybe we just need an implementation of the TNFS server for android (and iphone?). That way we can keep downloading stuff from atariage.com and then access those in the moment using the tnfs client you already developed. Now, regarding the idea of webserver "address book", I think it is seems simple and great.

I agree. SIO2PC is the cheapest and most efficient way to get your setup running, a good start. Later, probably, you will be tempted to get a multicart (like unocart, or avgcart). If you want to go very cheap and you are in USA you can get something like this: https://www.ebay.com/itm/FT232RL-FTDI-USB-3-3V-5-5V-to-TTL-Serial-Adapter-Module-for-Arduino-Mini-Ports/232428575643?hash=item361dd29b9b:g:6PcAAOSwL5pZfM4~ or this (no need to supply your own USB cable): https://www.ebay.com/itm/PL2303TA-USB-to-TTL-RS232-COM-UART-Module-Serial-Cable-Adapter-for-Arduino/382768151970?hash=item591ec27da2:g:sfIAAOSwOShcWLXN And if you don't want to waste an Atari SIO connector, you just need to connect 3 signals: TX->DIn(pin3), RX->Dout(pin5) and GND->GND(pin4) (do not connect +5Vdc) and download and run RespeQt. That is the cheapest you can go if you are inclined to build and play with cables and circuits. If you are in Europe, Lotharek (https://lotharek.pl/) sells a nice sio2pc via USB in his website. Regards,

What about the atari generating a qr code or similar? We scan the code with the smartphone so a tcp connection can be created to: option A, transfer the url, or option B, transfer the binary itself. Food for thought...

But the potential to browse select and boot an image or xex from, for example, pigwa, sounds very appealing to me (or from any other directory browseable website). It might be one very popular feature. Another idea: One the biggest reasons to have a sio2bt device right now for me is ability to test games or images posted in this forum as I am reading the posts: click the attachment, fire sio2bt app, and then select the latest file from the download folder and finally boot my Atari computer. So it might be extraordinary to somehow select an image or xex from atariage forum and boot or run the executable.

I modified sio2linux.c to accept P: data from the Atari computer and store it in a file. There you can see the commands sent. The Print Shop is slow... to much data transmitted. Details:

The ram of the module is pretty limited to hold the whole graphics mode page, probably directly drawing/writing to the spiffs line by line would make it...

Oh.. OK that is not great but at least you can just cut the legs of every ram chip you want to remove and then desolder those legs one by one. It is not that terrible if you do it that way.

Making a vertical pass-through version sounds great. I beleive that it easier to access when you want to press a button, an also it requires less clearance behind the computer or other device. The only problem would be to used the FujiNet device in the Lotharek sio splitter. Another topic: is there a way to boot the configurator without the need to emulate D1:? I am bringing this up since in the current state you need to keep turning on and off the real D1: I'm not sure about how useful that feature will be, but there is a whole discussion regarding usability, work flow, and usage cases for the device to be great from the POV of how it is going to fit into our current and diverse configurations. I personally don't like "design by committe" that much, anyway... Just a little disclosure.

BTW, do you the 130xe with 4 ram chips or the one with 16 ram chips? If you have the 4 ram chips it is pretty cheap and easy to replace the 2 extended memory chips and check if every works ok. You can get those in ebay very easy. Like a pack of 5 just in case. You want to replace them all.

I remember I check the oscillator functioning by measuring both the AC and DC voltages (with respect to ground) with a regular multi-tester. The output pin is the one located at the opposite of the sharp corner. I remember that the good one oscillator has both AC and DC voltages different (and far) from zero. I needed to do that since my multi-tester has frequency measurement by not up to 8MHz.

Writing just to report that my new (to me) Atari 850 (with 392 stamp in the label) has the most common firmware: 2cf990b9

I built my simplified prototype this weekend (only Din Dout Cmd and Gnd) and make it work after correcting some mistakes and I would like to say two things: - This is wonderful. Thank Thom for being the main contributor and force behind this development, and all the others for make this happen. - It is not clear (except for a old mozzwald post) that the ESP32 version keeps the 470 ohms resistors for each signal, but DOES NOT use the arrangement of transistors shown in the schem, posted by Thom (since it is a esp8266 schem, that is needed for esp8266 only). Instead only the DIODE is needed (if you want the board to be part of the SIO bus with other devices at the same time). I actually first took some wires with pins and did the following connections b/w a spare sio cable and the ESP32 module (without resistors): GPIO16------SIO pin5 DOut GPIO17------SIO pin3 DIn GPIO21------SIO pin7 Cmd GND-------- SIO pin4 GND and I powered the module thru the include USB connector. It worked. So then I moved to debug my prototype board, since I knew the module itself was working properly. Thanks again! Mauricio

I used something called spade drill bit to do the hole. A 5/8" one (not measured with caliper I just chose the one that looked fine/closest), and then I did some practice in a random piece of plastic, before going for the real thing. Others have used other methods, like using a regular drill bit to make small holes around the circle contour and then work with a file to get a perfect finish.

Yep, my white beauty power supply is made by Chelco.

Wow, top quality job Macin!

Maybe unrelated, but the response to the drive status looks a bit awkward to me, but it may be causing some hiccups perhaps... byte status[4]={0x10,0xFF,0xFE,0x00}; Instead, sio2linux starts with 0x10, 0x00, 0x01, 0x00 and then it changes the response if disk is Read only or if the disk geometry is different: static unsigned char status[] = { 0x10, 0x00, 1, 0 }; status[0]=(disks[disk].secsize==128?0x10:0x60); if (disks[disk].secsize==128 && disks[disk].seccount>720) status[0]=0x80; if (disks[disk].ro) { status[0] |= 8; } else { status[0] &= ~8; } Interestingly, bits 5, 6 and 7 are not mentioned in the Altirra HW ref manual (Or I missed that part). sio2linux code has this comment, an extract from Bob Wolley post in the usenet news: * Bob Woolley wrote on comp.sys.atari.8bit: * * at your end of the process, the bytes are * CMD status, H/W status, Timeout and unused. * CMD is the $2EA value previously * memtioned. Bit 7 indicates an ED disk. Bits * 6 and 5 ($6x) indicate DD. Bit 3 indicates * write protected. Bits 0-2 indicate different * error conditions. H/W is the FDD controller * chip status. Timeout is the device timeout * value for CIO to use if it wants. * * So, I expect you want to send a $60 as the * first byte if you want the OS to think you * are in DD. OK? Edit: this is what is done in RespeQt: void SimpleDiskImage::getStatus(QByteArray &status) { status[0] = m_isReadOnly * 8 | (m_newGeometry.bytesPerSector() == 256) * 32 | (m_newGeometry.bytesPerSector() == 128 && m_newGeometry.sectorsPerTrack() == 26) * 128; status[1] = 0xFF; status[2] = 0xE0; // Timeout for format ($E0) - Time the drive will need to format a disk (1050 returns 0xe0, XF551 0xfe) status[3] = 0; }

Motor is on MOST of the time. But when the program wants to talk with the disk drive (for example try to get a disk directory) the motor control goes off, effectively leaving the tx and rx lines disconnected from the bus (the modem keeps working and "spinning the wheels in the air"), that way the SIO bus can be used to talk with the disk drive. So for rverter devices (SX212) it is like concurrent mode all the time, and the motor crtl signal is a "hardware" solution.

Sorry my bad... recInProgress is the volatile var that goes inside the ISR: void ICACHE_RAM_ATTR isrCmd() { if (digitalRead(PIN_CMD) == LOW) recInProgress = true; else recInProgress = false; } The recCmdFrame() is called all the time, since it is inside the loop() function (Receive Cmd Frame and Process Cmd Frame): I have re-posted the the function using the code style that I just discoved in this forum.. sorry for the previous post... void recCmdFrame() { static byte ndx = 0; byte rb; while (Serial.available()>0 && newCmdReady == false ) { rb = Serial.read(); if (recInProgress == true) { cmdWord[ndx] = rb; ndx++; if (ndx >= 5) { if (checksum(cmdWord,4)==cmdWord[4]) { recInProgress = false; digitalWrite(PIN_MCULED, HIGH); ndx = 0; newCmdReady = true; Debug_println("passed cksum"); } else { //bad checksum, let's try reading more bytes as long as cmd low yield(); Debug_println("failed cksum"); ndx = 4; cmdWord[0] = cmdWord[1]; cmdWord[1] = cmdWord[2]; cmdWord[2] = cmdWord[3]; cmdWord[3] = cmdWord[4]; } } } } } void loop() { if (genmode==MODEM) { todo(); } else if (genmode==DISK) { recCmdFrame(); procCmdFrame(); } } Then I created two flags to move thru the machine states: newCmdReady which is initialized in FALSE and set to TRUE once command frame is ready and validated and recInProgress (receiving process in progress) which starts in FALSE and it is updated by the ISR. I am also attaching the INO , but it is just a simple starting and easy starting point idea of adding a short drive emulation to a modem program emulation, to boot the rverter handler and ICET or BOBterm, and then switch to modem mode for the rest of the time, until next boot. Nothing fancy.. I just like the idea of receiving and validating the cmd Frame first and also the idea of trying additional bytes in the serial buffer until the checksum works, instead to give up at the first try. Not sure how effective this strategy is in practical terms.. maybe not useful at all. mm.ino