Jump to content
IGNORED

Hardware based slow motion control for the Atari 800


lbaeza

Recommended Posts

Hello everybody


I am aware of this hardware add-on for the ZX Spectrum called the "Slomo".

This hardware was plugged on the microcomputer rear connector in order to control the speed it ran by turning a potentiometer.

I guess this was a useful device for passing the most difficult stages of certain videogames, where speed control was critical.

Attached to this post there are some pictures of this hardware, taken from the World of Spectrum.


Did the Atari computers have a similar hardware based slow motion control?


Kind regards,


Louis BQ

post-86-0-35041500-1532376653.jpg

post-86-0-01988400-1532376666.jpg

  • Like 1
Link to comment
Share on other sites

I don't think any such thing existed.

Fairly sure the NMOS 6502s require a certain clock rate to ensure refresh of internal registers - something along the lines of 100 microseconds / 1.5 scanlines on hold would likely be too much.

 

Such a device wouldn't be much use for most Atari games which are usually based on the VBlank rate. All you'd accomplish by adding wait state cycles is to make the program more likely to lag in it's rendering, so producing the annoying noncompatibillity like you see with many modern games and demos working on PAL but not NTSC due to more less cycles available per frame.

 

A more useful thing might be a modded OS where you could skip every second VBlank's user software processing though it'd be a hit and miss affair, some games would work with it and others might break.

Link to comment
Share on other sites

The thing with C64 - there's just the single software maintained IRQ vector which by default services the timer which is their equivalent of our VBI - the stupid thing being that even on PAL they have it running at 60 Hz. So yeah, the likely result might be unwanted speedup there, or unscheduled running of raster interrupt code.

 

On Atari there's a structured IRQ servicing routine with inbuilt priority. Any unsolicited IRQ where all the flag checks fall through is assumed to be a BRK by the OS which in itself would provide a decent waste of cycles.

But like I said, throwing away cycles on the Atari won't be beneficial for game slowdown in most cases.

Edited by Rybags
  • Like 2
Link to comment
Share on other sites

On Atari there's a structured IRQ servicing routine with inbuilt priority. Any unsolicited IRQ where all the flag checks fall through is assumed to be a BRK by the OS which in itself would provide a decent waste of cycles.

But like I said, throwing away cycles on the Atari won't be beneficial for game slowdown in most cases.

 

Yes. I forget to mention that, I know some guys build this solution in the 80s, but most times the effect was... crap.

 

Another way is to halt the CPU using RDY or HALT, but in both cases you get graphical disturbations quickly - and ANTIC´s timing went wrong - picture garbage.

Link to comment
Share on other sites

Hi R. Cade

 

Just found this video, it shows what you described:

 

 

Didn't know the same manufacturer did a C64 version.

 

All this conversation led me to this other question: Is it possible to freeze the video display of the Atari computers?

 

Like having a VCR pause button, so you can resume action after the button is pressed again....

 

Kind regards,

 

Louis BQ

Kind regards,

There is one for the C64 that hits the IRQ line at an adjustable rate. What it does to games is very unpredictable. Mostly, they just go crazy instead of slowing down...

Edited by lbaeza
Link to comment
Share on other sites

Glitchy as... but I do wonder is it in fact hitting NMI in which case the default handler would check for Run/Stop and just return, burning some cycles.

I'd have thought IRQ would be an unreliable method since lazy programming could just see it triggering the housekeeping timer code. Also since IRQ is level triggered a variable pulse would probably be an unreliable method since you could get multiple triggers in a row vs NMI which is edge triggered so you only need hold it low for 3-4 cycles to guarantee a single interrupt.

 

Actually, C64 has the /DMA signal on the cart port, so in theory a device could just pull that low to keep the CPU off the bus as a cycle burning method.

Edited by Rybags
Link to comment
Share on other sites

Since I had the 7400 built into my 130XE anyways for the SIO2PC interface I used the free ports for Bernard Pahl's "CPU brake". http://www.b-pahl.de/atari8bit/Computer/computer.html#bremse

 

Simply just works for many programs as long you don't lower speed too much (like a tenth of it's speed). Some games cause issues (VBI), as with anything non-standard you add as hardware. Nifty thing.

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