MichelS Posted December 22, 2021 Share Posted December 22, 2021 Hi, i'd like to share my recent "discovery" of an undocumented feature in our beloved little handheld console. I haven't read about this one anywhere, so for me this was all new. Now i'm hoping it's not only yesterday's news for you... Recently, i wondered what some registers and bits in Mikey and Suzy address spaces might actually be good for. Do these registers still exist in the production versions of Mikey/Hayato and do the bits have any effect? Or is the "documentation" on these registers just a leftover from early prototypes of the development-hardware? I'm talking about the sparsely documented registers like MTest0, MTest1, MTest2, timer magmode bits, Suzy parallel port registers, etc. Since i haven't found much on these topics here or elsewhere, i started my own experiments. One bit was exceptionally easy to investigate, yet it comes very "handy"? i think - UARTturbo (MTEST0 = $FD9C, bit4). Documentation states that UART baudrate is controlled by timer4 and the maximum baudrate is 62500. This baudrate is set by a timer4 backup value of 1 and a 1µs baseclock. The timer interval is 2µs then. For UART, this interval is frequency-divided by a factor of 8, giving an output interval of 16µs. So, every 16µs, one bit is shifted into (respectively out of) the UART shift register(s), which corresponds to said baudrate of 62500. I watched my Lynx transmitting data using this setup with a logic analyzer attached to the comlynx connector. Now, i was really surprised when i set the UARTturbo bit. This is what happened: The duration of one bit on the serial line went from 16µs down to 1µs - so that's a 16x speedup, giving a turbo transfer rate of 1000000 baud. Investigating further, it turned out, timer4 had no effect on the transmission anymore. In fact, i could stop the timer or omit the timer setup code completely. It seems, with the turbo bit set, the UART shift registers are directly clocked from the 1µs baseclock. No timer and no frequency divider involved anymore. This is my testcode: sei stz $FFF9 ; init comlynx lda #%00001101 sta $FD8C ; SERCTL: RESETERR, TXOPEN, PAREVEN (parity = mark) lda #%00010000 sta $FD9C ; MTEST0: UARTturbo ; wait for keypress here ; transmit bytes lda #42 wait: bit $FD8C ; test SERCTL bpl wait ; wait for TXRDY sta $FD8D ; write to SERDAT bra wait A lnx-file is attached. Press any button and it'll transmit the answer to the ultimate question of life, the universe and everything endlessly at 1Mbaud. Lynx I or Lynx II - both work. But can the Lynx feed the transmit buffer or empty the receive buffer fast enough to keep up with UART at that rate? It can. Transmitting one byte of data takes 11µs at 1Mbaud. That's 176 ticks or ~35 cycles (and that's all slow 5-tick-cycles assumed). Even with video dma/dram refresh eventually taking 28 ticks, it's enough time to e.g. fetch the next byte from memory, wait for the transmission buffer to become empty and refill it with the fetched byte ... in a tight loop at least. Ok - haven't tried UART interrupts. Maybe someone else will try and report back. I'm using turbo mode for my comlynx cartridge dumper now. After booting from flashcart and swapping carts (modified Lynx with bridged cartridge connector pins needed), i hit a button to start transfer. Downloading a 256Kb rom to PC at 1Mbaud takes about 3s. It's lightning fast. Without error detection/correction, i had a single corrupted byte in ~20 times test-downloading "Batman returns". That's for the Lynx connected to my PC via standard length comlynx cable (attached to a FTDI USB serial interface with a flaky 2.5mm female plug). Actually, i was surprised again i could set 1Mbaud for the FT232, but it seems to accept almost any parameter i throw at it... With some software-handshaking, the opposite data direction works as well. You just need a buffer and a fixed packet size smaller than that for uploading data to the Lynx, since there's not much time for complex program logic when data is coming in at that high a rate. How does turbo mode behave if multiple consoles are interconnected, i.e. with longer cables? I don't know. As i said - i have never seen this baudrate being mentioned or used before... Anyway, that's my part for now. I checked some of the other MTEST bits as well, but haven't investigated deeper by now. At least, the few i checked seem to be less useful. So - what else? Maybe somebody out there knows what e.g. the timer magmode bits do? Kind of PWM mode maybe? Or do you have anything else on the un(-der)documented features to share? It would be nice if we could collect some more information here... Merry Christmas everyone! UARTturbo.lnx 5 Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 Great finding. I will try this out during holidays. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 I tried it with uBLL from new_bll but no luck. I can see data arrives when I write to FDB0 what I get, but it does not detect the correct sequence "$81 P". But then, I cannot be sure the baud rate is set correctly on the PC. Attached an uBLL which by default uses 62500 and if a button is pressed during startup, is uses UARTturbo (background is green then). I use a CP2102 USB to serial. new_bll.zip Quote Link to comment Share on other sites More sharing options...
MichelS Posted December 22, 2021 Author Share Posted December 22, 2021 Do you receive any data from the lnx-file i attached? Make sure you're connected to the com-port on your PC prior to pressing a button on the lynx. I tested your file. I can see the background color changing - both at 62500 (red background) and 1M (green background) while the upload is running. But then nothing happens (for both). I tried to upload an .o-file with the .BS93 header. Is this correct or do i need to use a special program for uploading? I just tried it with a terminal (HTerm 0.8.5 on Win10). Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 1 minute ago, MichelS said: Is this correct or do i need to use a special program for uploading? I No, you need so send a special sequence $81, "P", start high, start low, len low ^ff, len high ^ ff Attached a simple program I use. Can be compiled with mingw. For COM7: sendobj -b 1000000 -p com7 file.o sendobj.zip Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 (edited) 7 minutes ago, MichelS said: Do you receive any data from the lnx-file i attached? Need to find a terminal program which allows me to set an arbitrary baudrate first. Hmm, GD does not start it?! Edited December 22, 2021 by 42bs Quote Link to comment Share on other sites More sharing options...
MichelS Posted December 22, 2021 Author Share Posted December 22, 2021 (edited) Ah - ok! Tried it with "2048.o" - works for me (both baudrates on my Lynx I): G:\Emulation\Atari Lynx>sendobj.exe -b 1000000 -p com5 2048.o Port: \\.\com5 Loading 2048.o Baudrate 1000000 Read 39199 bytes. Now writing ... and game starts! Edited December 22, 2021 by MichelS Quote Link to comment Share on other sites More sharing options...
MichelS Posted December 22, 2021 Author Share Posted December 22, 2021 (edited) Quote 24 minutes ago, 42bs said: Hmm, GD does not start it?! Haven't tried on GD - i'm usually using my Lynxman Flashcart. But the screen is not initialized, so you won't see anything happening on the Lynx. The source code i gave is almost the complete program (at $0200), except for the keywait part. It's less than 50 bytes so it fits into a single block encrypted header. Edited December 22, 2021 by MichelS Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 Ok, fine. So I need to get an FTDI USB<->Serial adapter. Any special things made to the cable? Quote Link to comment Share on other sites More sharing options...
MichelS Posted December 22, 2021 Author Share Posted December 22, 2021 Quote Any special things made to the cable? Not that i'm aware of - can't remember if i used a diode or just a resistor between RX and TX but i can look it up. I'll post a picture of the whole thing... Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 (edited) Ha, tried a different USB<->Serial and it works! (Its an FTDI232!) Edited December 22, 2021 by 42bs Quote Link to comment Share on other sites More sharing options...
MichelS Posted December 22, 2021 Author Share Posted December 22, 2021 (edited) NICE! For the record: here's the picture. Seems i was lazy - RX (orange) and TX (yellow) are just soldered together at the female plug. I think both are connected inside the lynx without anything in between as well. At least the FTDI chip obviously doesn't care... Then there's only GND (black), all other wires are cut. Edited December 22, 2021 by MichelS Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 But for interrupts it seems to be to fast. At least does the BLL-Background Loader in my demos not work. I see interrupts coming in (HBL stops), but I guess I get an overrun. Anyway, with a Reset button, uBLL there is practially not more need for it. Great finding (I must repeat). Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 new_bll:uBLL updated. Defaults to TurboMode, fallback to 62500Bd on key-press. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 (edited) CP2102 is 3V3 only and specified for 1MBs. So it is likely that the Lynx cannot detect level change. Edit: The FTDI switched 3V3 works as well. So it seems the 1MBs is the limit for the CP2102. Edited December 22, 2021 by 42bs Quote Link to comment Share on other sites More sharing options...
MichelS Posted December 22, 2021 Author Share Posted December 22, 2021 Might be the problem - my adapter can be configured to 3.3V or 5V by a jumper. Quote But for interrupts it seems to be to fast That's what i had suspected. It might still be usable with interrupts though: using a software RTS/CTS protocol: Send a single byte first ("request to send") and let the interrupt in the receiver occur. Receiver replies with a "clear to send" byte just prior to entering a tight loop for receiving more data. If you send fixed-size packages this way, it might work... Quote Link to comment Share on other sites More sharing options...
Cyprian Posted December 22, 2021 Share Posted December 22, 2021 great finding @MichelS Quote Link to comment Share on other sites More sharing options...
42bs Posted December 22, 2021 Share Posted December 22, 2021 2 hours ago, MichelS said: Might be the problem - my adapter can be configured to 3.3V or 5V by a jumper. That's what i had suspected. It might still be usable with interrupts though: using a software RTS/CTS protocol: Send a single byte first ("request to send") and let the interrupt in the receiver occur. Receiver replies with a "clear to send" byte just prior to entering a tight loop for receiving more data. If you send fixed-size packages this way, it might work... I think it will be sufficient to have small delays after $81 and P, these are received via interrupt. The rest is fetched via polling. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 23, 2021 Share Posted December 23, 2021 I added a delay between the command bytes this was one step. But the loader must be changed as well: JSR/RTS to a read-byte function takes to much time. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 23, 2021 Share Posted December 23, 2021 Just trying my FlashCard writer and with little changes to the loading part (there is not much one can do besides loading from ComLynx) it works. If only the flash writing would not need the address jumps Quote Link to comment Share on other sites More sharing options...
42bs Posted December 23, 2021 Share Posted December 23, 2021 I notice with the FTDI that it is somehow powered by the Lynx TX line and if connected to the PC the Lynx cannot be powered on reliable. I ordered another set of PCBs and hope this effect is a problem of this specific PCB. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 23, 2021 Share Posted December 23, 2021 23 hours ago, MichelS said: NICE! For the record: here's the picture. Seems i was lazy - RX (orange) and TX (yellow) are just soldered together at the female plug. I think both are connected inside the lynx without anything in between as well. At least the FTDI chip obviously doesn't care... Then there's only GND (black), all other wires are cut. Do you have a LCD replacement? I wonder, because the Lynx with a new LCD (BennVenn/McWill) do not really power off with the USB adapter attached. If I add a diode in the RX-Line, it works. But then the 1MBd not Quote Link to comment Share on other sites More sharing options...
+karri Posted December 23, 2021 Share Posted December 23, 2021 Should not the RX line be connected directly to the ComLynx data and the TX line going through a diode? I mean that if TX is "0" you want to pull the line down. If TX is "1" you do nothing. So the diode is pointing towards the FTDI Tx pin. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 23, 2021 Share Posted December 23, 2021 Even if I do not connect the tx line, the adapter drains power from the Lynx. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 23, 2021 Share Posted December 23, 2021 One application I have been planning to make one day is a Hero Quest client/server game. The idea is to run the game master screen on a laptop (Windows or Linux). On the laptop you have the tools for building the level with all the items, enemies etc. At the start of the game the server broadcasts the world to all clients. The clients save the world in eeprom with all visibility bits as "hidden". Then the game takes turns from one client to the next. The game master can also play some character if he wants. The ROM could contain all the animations and sprites that could be used in the game. It could also include a few scenarios for stand-alone gaming. But the ROM would not have an game editor. The server including the editor could be on a Pi Zero. It has a serial port that can be programmed to non-standard baud rates. So no FTDI is needed. And on the Lynx 2 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.