Jump to content
IGNORED

ST Game cartridge?


barnieg

Recommended Posts

I only know of one cart ever made for the ST in its original run, and that was a RC Helicopter simulation. It used the cart for the custom RC controller.

 

The R/C Aerochopper game seems to be a special case. It has software on the card but also needs software on floppy.

 

As for other cards, there were also two hacker/ripper carts:

 

Then there was the Atari Diagnostics card. Further the Spectre Apple Mac emulator needed the original Apple ROMs on cart. Then there were a few carts with utilities.

 

There were various sample cartridges, video digitisers, hand-scanners, real-time clocks and even teletext decoders that used the cartridge port but those did not store the software of the cart. The game B.A.T. had a dongle used for outputting digital sound and was also used as copy protection. But again the software was still on disk.

 

Then you had also the ROM-disk that used bank-switching to have a higher capacity than 128KB and a whole bunch of eprom chips (I believe even on a 2nd PCB bolted on the main PCB). There was a utility that generated the eprom images from the programs you wanted on the ROM disk. Unfortunately I can't find any info on this on the internet.

 

Finally there was the Discovery cartridge that had special hardware to copy protected disks.

 

More info about carts in this thread.

 

 

Robert

  • Like 1
Link to comment
Share on other sites

 

The R/C Aerochopper game seems to be a special case. It has software on the card but also needs software on floppy.

 

As for other cards, there were also two hacker/ripper carts:

 

Then there was the Atari Diagnostics card. Further the Spectre Apple Mac emulator needed the original Apple ROMs on cart. Then there were a few carts with utilities.

 

There were various sample cartridges, video digitisers, hand-scanners, real-time clocks and even teletext decoders that used the cartridge port but those did not store the software of the cart. The game B.A.T. had a dongle used for outputting digital sound and was also used as copy protection. But again the software was still on disk.

 

Then you had also the ROM-disk that used bank-switching to have a higher capacity than 128KB and a whole bunch of eprom chips (I believe even on a 2nd PCB bolted on the main PCB). There was a utility that generated the eprom images from the programs you wanted on the ROM disk. Unfortunately I can't find any info on this on the internet.

 

Finally there was the Discovery cartridge that had special hardware to copy protected disks.

 

More info about carts in this thread.

 

 

Robert

 

Interesting thread from ages ago. Deskcart! sounds awesome. Imagine had they made that and also built in the ramdisk features of the other carts out there into it. I named "Practical Peripherals" instead of "Practical Solutions" accidentally. I always thought their battery back-up cartridge with the pass-through connector was sweet. In hindsight, I should've bought it for my 1040STf when it came out. I loved their Mouse Master device.

Link to comment
Share on other sites

More info about carts in this thread.

 

I was given (I think it was a copy of) the Backpack cartridge mentioned in that thread, may be still in the loft somewhere at home. It came with a very small desk accessory that allowed you to access the utilities on the cart while running other GEM programs. Quite handy if you didn't have much memory, and the ability to run a clock and a calculator alongside another program is the holy grail of multitasking ;) If you didn't load the desk accessory at boot time you couldn't access the Backpack. Someone uploaded a few photos of the Backpack here.

Edited by galax
Link to comment
Share on other sites

I don't think that B.A.T. games had cartridge dongle - as I seen in code, it was on serial port.

 

It seems B.A.T. II had a serial dongle and although the MV-165 cart was supported, it was not included.

 

B.A.T. came with the MV-16 cartridge but I see no mention of a separate dongle.

 

I would have thought that if you supply a cartridge for sound that it would be easy to add some copy protection dongle cicuitry too. But on Atari-Forum there is a picture of the MV-16's PCB and it is just a cheap A/D converter using a resister ladder and an amplifier. There seems no circuitry for a decent dongle protection. Thus it indeed seems the MV-16 was not used as protection dongle and that the B.A.T. game did not use a protection dongle (just manual look-up protection) or that it had a separate serial dongle like B.A.T. II.

 

Does somebody here have the original B.A.T. who could confirm if the games plays without the MV-16 cart and if it contained a serial dongle?

 

 

Robert

 

 

 

Edit: This French page also has some info about the B.A.T. dongle. Here it seems B.A.T. came only with the MV-16 cart and B.A.T. II came only with a serial dongle.

Link to comment
Share on other sites

 

It seems B.A.T. II had a serial dongle and although the MV-165 cart was supported, it was not included.

 

B.A.T. came with the MV-16 cartridge but I see no mention of a separate dongle.

 

I would have thought that if you supply a cartridge for sound that it would be easy to add some copy protection dongle cicuitry too. But on Atari-Forum there is a picture of the MV-16's PCB and it is just a cheap A/D converter using a resister ladder and an amplifier. There seems no circuitry for a decent dongle protection. Thus it indeed seems the MV-16 was not used as protection dongle and that the B.A.T. game did not use a protection dongle (just manual look-up protection) or that it had a separate serial dongle like B.A.T. II.

 

Does somebody here have the original B.A.T. who could confirm if the games plays without the MV-16 cart and if it contained a serial dongle?

 

 

Robert

 

 

 

Edit: This French page also has some info about the B.A.T. dongle. Here it seems B.A.T. came only with the MV-16 cart and B.A.T. II came only with a serial dongle.

 

Interesting hardware. But I thought people here state the ST Cartridge Port has too little bandwidth - or possibly too few address lines - to serve as a decent option to add sound chips to the ST whether we're discussing the likes of the STe's DMA chip, the Falcon's DSP, POKEYs, or better Yamaha chips like the YM2151.

Link to comment
Share on other sites

ST cartridge port is connected directly to CPU bus. So, it's bandwith is 2MB/sec. In practice it means about 1.5 MB/sec with CPU code. But only if reading ROM content. Writing is not possible without some tricks, because design simply supports not write. To make write possible designers used address lines to pass data to cartridge based adapters. First HW add-on for ST what I made was EPROM programmer. For cartridge port - and that worked on that principle. In other words, write can be much slower than read. But for some DMA audio of not high quality may be sufficient - 100 KB/sec is enough. Other problem is that all it loads CPU highly.

In case of CATA write is solved in very special way, using fact that IDE disk do address increment self, so we can just push data in row to port, without taking care of address on cart port.

Link to comment
Share on other sites

ST cartridge port is connected directly to CPU bus. So, it's bandwith is 2MB/sec. In practice it means about 1.5 MB/sec with CPU code. But only if reading ROM content. Writing is not possible without some tricks, because design simply supports not write. To make write possible designers used address lines to pass data to cartridge based adapters. First HW add-on for ST what I made was EPROM programmer. For cartridge port - and that worked on that principle. In other words, write can be much slower than read. But for some DMA audio of not high quality may be sufficient - 100 KB/sec is enough. Other problem is that all it loads CPU highly.

In case of CATA write is solved in very special way, using fact that IDE disk do address increment self, so we can just push data in row to port, without taking care of address on cart port.

 

So, wouldn't a cartridge-based RAM Disk be self-defeating because the write tricks slow performance down?

 

And does it have to be bankswitched or mapped differently if the ST already has 4/8/14MB of actual "ST RAM"?

Link to comment
Share on other sites

 

So, wouldn't a cartridge-based RAM Disk be self-defeating because the write tricks slow performance down?

 

And does it have to be bankswitched or mapped differently if the ST already has 4/8/14MB of actual "ST RAM"?

No. Slowdown happens only during disk access - CF card access today. Then it is 100%, and in case of write must disable all other activities on bus, so interrupts too. But that's nothing too bad, because TOS does similar - you must wait until disk operation is finished. And write is not much used in fact. Just to add that regular interrupts as Vblank and Timer-C (200Hz) are performed well even during write, because driver enables interrupts after every sector - so about 4000 times/second.

There is no bank switch - that has no sense in case of IDE port. All disk access is performed in 64 byte narrow I/O address space. What is in cartridge address area, so affects not at all possible RAM expansions, or TOS upgrade.

But cartridge port will be not usable for anything else - forget idea to add there something other when CATA is attached.

 

My latest idea is to use new system for Floppy Image Runner:

Instead holding image in RAM - what self means that min RAM needed is 2MB - because we can not have enough free RAM if 720 KB is used for ..

Using CF card's special dedicated partition to hold floppy images. Then access them with simple low level driver - what is placed in cartridge ROM.

So, no RAM taken by floppy image.

No RAM taken by driver - we even don't need extra disk buffers because images will be small, so can stay at 512 byte sectors.

In case of multi floppy SW best is to put all files in single image, what may be up to 32 MB.

Active image will be selected after reset.

Another great benefit is that may write in images.

Idea is to be possible to mount 1-2 images as virtual floppy A and B. That will give max compatibility with SW.

There is no more RAM allocated than in case of running SW from real floppies - and that will be good for many SW, not to mention that whole thing will work with even 512KB machines.

Above concept is possible with usual mass storage adapters - like UltraSatan, but then we can not have driver in ROM, so must place it in RAM - but that can fit in only 1KB - not usual driver, just driver for floppy images.

However, I will start with cartridge port version, since it will give best results.

Link to comment
Share on other sites

  • 7 months later...

So was an actual cart ever realized?

For holding Atari game self - no. There was audio extension for game B.A.T. - MV 16, what was supported with some audio SW too. Not much good quality - cheap solution.

 

I'm in process of doing pure, simple cartridge versions of some popular games - as suggested those published by Atari self, and they are usually short, so will fit. + Others.

Like: Starglider (without long (in bytes) title audio), Paperboy, Outcast, Boulder Dash, Chubby Gristle, GGS, Goldrunner ...

That will go with simpler cartridge v. - 8-10 games on one, selectable. On mass storage v. can use regular hard disk adaptations + virtual floppy.

Link to comment
Share on other sites

  • 2 years later...

On th other hand, you also devloped CATA, and all the ST games will snuggly fit onto a CF card should anyone (finally) be willing to mass produce the CATA.

I spotted this while looked over some cart. port related old threads. Could say that this is good example of how bad it can go when people jumps in without reading earlier posts, and even thinking not enough about subject.

Because this was started about "ST Game cartridge" . I just explained that you can go rather on some Flash card based solution if want larger or many games. And it must not be then connected to cartridge port, same effect can achieve with ACSI port based storage, for instance.

As recently said, I will go now on producing CATA somehow. But there are possible problems on ST machines because much bigger signal delays (slower Glue chip).

Will probably talk with Lotharek. Exxos said once that will not go in it, because my ACSI-CF adapter design is bad - not exactly those words, but that was meaning.

Considering true game cartridges - depends on interest. I will make some poll to see interest.

  • Like 1
Link to comment
Share on other sites

  • 1 year later...

Hi, i m from Germany, so please excuse me for my different ans maybe (bad) english....

Now, i have time to play with my just 5 Years old Atari Hardware.

Just made an Eprommer, and had make two PCBs of 128K cartridges.

After buying some 27C512 Eproms, i still try to use these on the Cartridges for my 140STF and Mega 4 ST.

 

Unfortunately, i need some Help and advise. i found here and on other Sites some xxx.STC-Files. (Thx to ParanoidLittleMan). Found only an Option to Split thiese ones using Windows XP (Bin2HEX) because my Prommer want to have Intel-Hex-Files  to write Eproms.

i can Split to two Parts of 64Kb, but i have no success to get this working on my Cartridges.

 

Can someone give me a Step by Step Help?

Should i program both Parts (xx.lo and xxx.hi) from same Adeesses in Eproms?

 

Thanks a lot.. its very funny to do Things now, that i have done 35 Years before. 

 

 

  • Like 1
Link to comment
Share on other sites

STC files have added 4 zeros at start. You need to cut them off with some Hex editor. Then file length will be correct - 131072 (STC is 131076) .

Before Bin2HEX you need to split binary content of cartridge to Hi and Low parts. What means:  first byte to Hi, second to Lo, third to Hi, fourth to Lo ... etc.

For that can use my ROMSPLIT program (with Atari ST emulator for instance) http://atari.8bitchip.info/astopensw.php

It's for TOS split, so 256 KB long files in case of split in 2 parts. Will get 2x 128 KB files, but with empty second halfs, what just cut off with hex editor. Then will have 64 KB long HI and LO files . 

 

Link to comment
Share on other sites

Hm, thanks for these Tipps, just tested it with your Hello World.. it worked...  Hurray...

 

Hm, done the same with the Revcart.STC, but i got very different Filesizes,

STC without 4 Bytes its ok, 131072, 

after Romsplitt, the filesize remains at 131072 part (hi & lo), ok. can delete the half  with 0xED on my Mac. (64.912 Bytes? )

after Bin2Hex i get around 182kB (Intel Hex-Format), burning Eprom stopps at 0FD90 Adress. is that right? Burn just the second Part (Lo) and will test again...

 

Edited by SparkX
Link to comment
Share on other sites

Good Morning, i got it.

Thx again to ParanoidLittleMan for the Tipp to splitt in even and odd.

The (Windows) Bin2Hex-Package contains an app "Splitt2" that splitt a file in two Parts, even and odd, with type in the result Filesize (here 64kB).

after this run the two files with Bin2Hex to convert the ASCII to Intel Hex-Format.

Burn this with Eprommer to Eprom 27C512, that works fine. Just played Revenge of the Mutant Camels.

Thanks again, stay healthy ....

My Prommer: -> https://s-huehn.de/elektronik/epromprog/epromprog.htm

 

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

I don't think that Magic can work from ST cartridge. Cartridge support 128 KB max. Magic, at least later versions is 256 KB, and on different address space. Maybe some partial version, compiled for cartridge, what works together with existing TOS ROM ?  I don't think that is interesting really.

 

Img = Image . In this case it is simply binary content of ROM. They are extracted, and you can see machine code in them directly.

Intended to burn in EPROMs, then can put in Atari and use. But, if you read page carefully may see that you can use them with emulators. Like Steem. And with later Hatari versions, I guess.

Well, it was 10 years ago, so I may do some tests and memory refreshing ...

Link to comment
Share on other sites

  • 6 months later...
2 hours ago, Cuzuco said:

Hello,

 

I am new to the forum, when I was a kid I had an Atari 130st and I remember that I could use the Atari 2600 cartridges on it to play those games.
is it the same with the Atari 520st? Or those aren’t compatible?


That is impossible.  Even the 130XE couldn't play Atari 2600 cartridges.   yes the 520ST is a 512k version of the prototype 130ST.  The 130XE series was a 128k version of the old 8-Bit Atari 800/XL series.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, tjlazer said:


That is impossible.  Even the 130XE couldn't play Atari 2600 cartridges.   yes the 520ST is a 512k version of the prototype 130ST.  The 130XE series was a 128k version of the old 8-Bit Atari 800/XL series.

Sorry,

 

My mistake. Actually it was a 130xe. And from what I’ve read it was able to play cartridges from atari 400 and 800. 
So now I am wondering if the 520st did also have some games produced as cartridges or no one used this way os distributing games for that machine?

I am about to buy a 520st and I’m interested on the easiest way to get games and other programs for that machine. How would I transfert any game from the internet to a floppy disk?

Link to comment
Share on other sites

I can't find it now but the Microdeal Sampler (I think) that I bought for my old 520STM back in the mid 1980s had a DAC inside it and it could play the samples via the DAC in the sampler plugged into the cartridge slot. I think that was the only cartridge I had for my ST, never got around to buying the excellent FAST ST Basic on cartridge.

  • Thanks 1
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...