Jump to content
IGNORED

Exploring un(-der)documented features of the Lynx


MichelS

Recommended Posts

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

  • Like 5
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by MichelS
Link to comment
Share on other sites

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 by MichelS
Link to comment
Share on other sites

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.

USB-Serial.jpg

Edited by MichelS
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

USB-Serial.jpg

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 :(

 

Link to comment
Share on other sites

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.

HQ.thumb.jpg.9009d91331fc5ad15c2378347d872c88.jpg

And on the Lynx
post-2099-1133418691.png.bd53f77cac2b33a6e89347bf7948b13b.png

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...