Jump to content

Photo

Using magnetic tape


12 replies to this topic

#1 LX.NET OFFLINE  

LX.NET

    Dragonstomper

  • 765 posts
  • Location:The Netherlands

Posted Sun Feb 10, 2019 2:55 PM

Hi All,

 

Wondered about the following: would it be possible to use the magnetic tape drive features of the Lynx for some purpose?

Some facts I gathered today:

 

  • Pin 28 (TAPE1) and Pin 29 (TAPE0) of the Mikey chip are present (although they are connected to ground)
  • The timers 1, 3, 5 and 7 refer to Mag0a, Mag0b, Mag1a and Mag1b respectively
  • Addresses FD84 (MAGRDY0) and FD85 (MAGRDY1) appear to offer a 7th bit to signal "Mag tape ready" for the channels 0 and 1. The bit is reset on read.
  • The addresses of the 
    • FD04 = TIM1BKUP MAGA
    • FD0C = TIM3BKUP MAGB
    • FD14 = TIM5BKUP MAGC
    • FD1C = TIM7BKUP MAGD
  • The addresses for timer static controls (TIMXCTLA, where X is 1, 3, 5 or 7) refer to magmode with bit $20.
    "Unused in timers 0,2,4,6 / Magmode in timers 1,3,5,7 $20 ..1....."
  • The documentation says: "The circuit for reading magnetic tape is in Mikey. However the Mikey ROM does not currently activate the tape mode. When the decision is made, the ROM may have to be changed. The alternative would be to use an external ROM that would activate the tape circuits."
  • "The other 5 timers are for general software use. POOF. See the mag tape description."
  • Pin 9 is MOTORON and is referred to from FD87 (SYSCTL1)
    "FD87 = SYSCTL1.Control Bits.(W)
    reset x,x,x,x,x,x,1,0
    B1=power (1 = on)
    B0= Cart Address Strobe (also counter reset) (was MotorOn)
    "
  • Older chipsets might be needed. From the Epyx Development Kit source files, it mentions in harddefs.i in version 1.2 and 1.3 of the kit that magnetic tape related definitions have been removed. 
    Version 1.1 (in text file Release_1.1) 
    "The following files have been removed, and should no longer be
    referenced by your code:
      6502:include/aio2defs.i
      6502:include/io32defs.i
      6502:include/sys.i
      6502:include/tapedeck.i
      6502:macros/tapedeck.mac
      6502:src/controls.src
      6502:src/handymath.src
      6502:src/sprite.src
      6502:src/tapedeck.src
    "

    Version 1.2:
    "6502:include/harddefs.i - Removed MAGRDYx definitions
    (MAGTAPE features are removed from new chips)
    Added new stereo hardware definitions
    "
    Version 1.3:
    "6502:include/harddefs.i - removed the MAGxx names for timers
    added READ_ENABLE bit definition for IODAT
    "

    harddefs.i change log:
    "* 7-Mar-90 SHL  Removed MAGRDYx definitions"
    "* 27-Jun-90 SHL  Removed MAGxx alternate names for timers"
     
  • Epyx Development Kit refers to:
    * 2 Jan 89 -RJ  Added TAPE_RECORDING definition and examples
    *    of calling tape-recording macros

Since most magnetic tape references have been removed around early 1990 (release 1.1 on 27-2-1990, release 1.2a in 29-3-1990, Release 1.3.3 in 28-6-1990), and the Lynx was released on September 1st, 1989 it might be that the hardware was changed after release of the first Lynx 1 devices.

 

Anyway, any ideas and opinions are welcome.

 

Sources; 

  1. http://www.monlynx.d...x/hardware.html
  2. https://atariage.com...nx_UL_High.html
  3. Epyx Development Kit source code files
  4. http://atariage.com/...ic#entry1702760


#2 karri ONLINE  

karri

    River Patroller

  • 2,592 posts
  • Location:Espoo, Finland

Posted Sun Feb 10, 2019 11:27 PM

The sequential reading of bytes from the cart already mimics the magnetic tape. Same with the homebrew eeprom hacks. I am really glad they ditched the physical magnetic tape. Just think about the frustration in rewinding the tape to read in the next graphics in the middle of a game ;)

 

Today there is all kind of powerful serial interfaces like I2C with a clock and data pins. Or SPI with CLK, MISO, MOSI pins. I have connected LED strips to some cart pins in order to see if it would be possible to control external equipment with the Lynx. It works, sort of.

 

It might be interesting to see if the timer inputs or outputs could be seen on any Mikey pins. Perhaps RJ would know.



#3 vince OFFLINE  

vince

    Star Raider

  • 79 posts
  • Location:PARIS (FRANCE)

Posted Mon Feb 11, 2019 1:10 AM

I used those signals for SPI purpose on the Ouragan's cartridge : accelerometer is connected to those pins.



#4 karri ONLINE  

karri

    River Patroller

  • 2,592 posts
  • Location:Espoo, Finland

Posted Mon Feb 11, 2019 1:25 AM

I used those signals for SPI purpose on the Ouragan's cartridge : accelerometer is connected to those pins.

 

Audin for reading and some address pin for clock?



#5 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Dragonstomper

  • 500 posts
  • Location:Finland

Posted Mon Feb 11, 2019 1:43 AM

I am really glad they ditched the physical magnetic tape. Just think about the frustration in rewinding the tape to read in the next graphics in the middle of a game ;)

 

Lol :D I was also glad to get rid of C cassettes for decades, but I've gotten nostalgic about them again. It's fun to see people playing their own music from tape on old colorful cassette players from the 80s. I recently got myself this one (because ebay has been cleaned up from nice looking 'boom boxes', at least those with line-in, and they're horribly expensive). https://cdn5.elektro...ettenplayer.jpg

 

Also I'm really into tape loading on the c64, the tape loaders with a loader image and loader music are really, quoting Nostalgia Nerd - 'Superior to any technology of today' ;D

 

All joking aside, there's the obvious downsides to tape, but there could possibly be some sense in using them: Small 'one load' games that fit into ram would probably load reasonably fast. It can be fun (it is fun!). C Cassettes are still produced and they're cheap. Not that you didn't already made it cheap and easy to produce real carts for the Lynx Karri (thanks)!

 

The biggest issue would be that most people probably have thrown away their tape players by now, and I'm not sure if you'd need some sort of 'proper' tape player designed for use with computers, I mean audio is audio, but there's all the azimuth tape head alignment and volume issues.


Edited by Turbo Laser Lynx, Mon Feb 11, 2019 2:22 AM.


#6 karri ONLINE  

karri

    River Patroller

  • 2,592 posts
  • Location:Espoo, Finland

Posted Mon Feb 11, 2019 2:18 AM

Tapes are nostalgic. But you could as well make a Bluetooth dongle for streaming in data. Shorter rewind times.

 

The Lynx has already had the BLL loader for streaming in anything through ComLynx. I used it a lot with many homebrew carts for testing my own creations on a real Lynx. But today the fastest way for me is to just plug in an empty flash cart and burn the lnx image on it. This is also the best option as I am using eeprom's to store progress in my current, amazing, 30 years Lynx birthday game to be released in September.



#7 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Dragonstomper

  • 500 posts
  • Location:Finland

Posted Mon Feb 11, 2019 2:55 AM

Yeah, I remember testing my own games on a real Lynx with your oldest flashcart over comlynx, it was quite slow and painful in comparison to what we have now, especially if/when there were some bugs and you'd have to do it over and over. I always did like the 'tape-loading-like' flashing screen though :) Tapes are only good for when having dedicated time for 'maximum' nostalgia feeling. I do the same on the Lynx, if I play something 'casually' I use the flash cart, but when I sometimes have the time to plan in a 'Lynx gaming night' I use the old 'real carts' for the feeling. :) Obviously most of the time convenience is the deciding factor.


Edited by Turbo Laser Lynx, Mon Feb 11, 2019 3:07 AM.


#8 sage OFFLINE  

sage

    Dragonstomper

  • 985 posts
  • Location:Germany

Posted Tue Feb 12, 2019 7:58 AM

not if you use it with 62500 baud ;-)



#9 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Dragonstomper

  • 500 posts
  • Location:Finland

Posted Fri Feb 15, 2019 1:16 AM

According to this calculator: https://www.calculat.../data_rate.html

That would be 7.62939453125 kb / second. Superfast Lynx tape-loading, nice! :> I'm sure there's some limitations that doesn't make this a viable approach in reality.


Edited by Turbo Laser Lynx, Fri Feb 15, 2019 1:17 AM.


#10 karri ONLINE  

karri

    River Patroller

  • 2,592 posts
  • Location:Espoo, Finland

Posted Fri Feb 15, 2019 1:27 AM

If you send 62500 bits per second and your frame is start bit + 8 data bits + parity + stop bit = 11 bits/byte. Then your transfer rate is 62500/11 = 5681 bytes/sec



#11 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Dragonstomper

  • 500 posts
  • Location:Finland

Posted Fri Feb 15, 2019 6:16 AM

Ah, we had something about serial communication /checking that the data transfered is correct in school many years ago, but haven't given it a thought since then. That would still be very fast though, at least in Lynx and tape measurements. :)


Edited by Turbo Laser Lynx, Fri Feb 15, 2019 6:17 AM.


#12 karri ONLINE  

karri

    River Patroller

  • 2,592 posts
  • Location:Espoo, Finland

Posted Fri Feb 15, 2019 8:25 AM

Actually magnetic tape has a frequency response of 30Hz to 15kHz. The speed 62.5 bps would at least require 32kHz. Or some clever modulation that can store more. In any case using tape is not trivial at these speeds.

 

The first tape systems were running at 110 bps or 300 bps back in time. Usually using modem techniques of two frequencies alternating for sending bit zero or bit one.


Edited by karri, Fri Feb 15, 2019 8:39 AM.


#13 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Dragonstomper

  • 500 posts
  • Location:Finland

Posted Sat Feb 16, 2019 6:41 AM

Yes, I had to check up some numbers and I found this on Lemon64. So it seems the standard tape loading on a c64 is ~415 bits/s and a common turbo ~4320 bits/s. So 'ram only' games would take a little while to load even with 'turbo speeds'. It is quite slow when looking at the numbers :D

 

 

Quick empirical experiment:

manic_miner.prg ; 38390 bytes

Save to .tap using a) plain CBM ROM loader, b) Turbo 250.

a) rough layout and timings:

pilot 10.5 sec
header first 1.9 sec
header repeat 1.9 sec
pause 0.3 sec
pilot 2.0 sec
data first 6 min 1.3 sec
data repeat 6 min 1.3 sec

--> total time for loading a 38388 byte program: 12:19.339.
--> effective data rate: 51.9221 bytes/sec = 415.3764 prg data bits per sec.

b) rough layout and timings:

pilot 2.2 sec
header 0.4 sec
pilot 0.9 sec
data 1 min 11.5 sec (including trailer)

--> total time for loading a 38388 byte program: 1:15.007
--> effective data rate: 511.7922 bytes/sec = 4094.3379 prg data bits per sec.

Then ignoring all pilots, headers, trailers, sync trains, etc, and looking at EXACTLY the data representing EXACTLY 38388 bytes (note that I ran TAPClean before this step, and apparently that made the ROM loader parts slightly slower...):

a) 38388 bytes in 6:09.081 = 104.0097 bytes/sec = 832.0775 prg data bits per sec.

b) 38388 bytes in 1:11.076 = 540.0979 bytes/sec = 4320.7834 bits per sec.

Hmm .. Really? I had expected slightly lower numbers for Turbo 250 ... icon_razz.gif Maybe there just happened to be lots of 0-bits in this particular game ... icon_biggrin.gif

 

According to this page: https://obsoletemedi...-cassette-data/

"A rate of 2000 bit/s equates to a capacity of around 660 KB per side of a 90-minute tape."

I guess that would mean ~2,5Mb on a 90min C cassette at ~4000 bps.


Edited by Turbo Laser Lynx, Sat Feb 16, 2019 6:50 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users