TURBO CARD for XE ATARI

[pirx]

Fantastic times, great news!

 

Coder question - is it possible with Rapidus to feed color registers faster, i.e. are more color changes per scan line possible?

[danwinslow]

Fantastic times, great news!

 

Coder question - is it possible with Rapidus to feed color registers faster, i.e. are more color changes per scan line possible?

 

Yes, I was wondering that too.

[JoSch]

 

New Device is the common name for peripheral devices connected through parallel interface (PBI - XL models) or CART/ECI (XE models). All computers starting from 600XL/800XL models with original operating system are able to work with New Devices, however some of XE models (65XE w/o ECI and XEGS) need an extra hardware modification.

Old 400/800 and 1200XL computers have operating system without New Device handling routines, so they are not able to work with New Devices. These models require more modifications done in hardware including OS replacement, but installation of Incognito in 800 or Ultimate1MB in 1200XL should help here a lot.

 

Thank you for the informations.

[danwinslow]

I am actually planning on writing an Atari emulator to run on my Turbo-equipped 1MB Atari. I figure that will be the ultimate in geekiness and I will achieve Nerdvana thereby. Ommmmmmmm.

[pixelmischief]

I am actually planning on writing an Atari emulator to run on my Turbo-equipped 1MB Atari. I figure that will be the ultimate in geekiness and I will achieve Nerdvana thereby. Ommmmmmmm.

Thou hast lost an eighth!

[ricortes]

Fantastic times, great news!

 

Coder question - is it possible with Rapidus to feed color registers faster, i.e. are more color changes per scan line possible?

 

IMO: Based on perusing the '816 instruction set: There should be lots of opportunities for software hacks/improvements in existing software. Couple of examples.

 

Direct push of processor registers. Normally when we do a DLI and use a register we have to save it with something like ~

PHA

TYA

PHA

TXA

PHA

... ;code that does something

PLA

TAX

PLA

TAY

PLA

and exit.

This would be replaced with

PHA

PHX

PHY

... ;code that does something

PLY

PLX

PLA

and exit

This would work in compatibility mode with the 65C02.

 

The 65816 instruction set includes a memory block move, should be almost as fast as DMA. It's also quite a bit shorter even with extra code switching mode from 65C02 to 65C816 and back again. Maybe 15 or so bytes shorter so you get a little extra room for programs and quite a boost in execution of the move. Of course there are probably better ways of doing it with 15 megs of memory available, but you should be able to brute force memory moves at 30+ frames per second for animation. At 8k per screen, 1875 frames of animation. Ditto for some of the other features that are standard practice on other computers. For example, a wav player on an Atari should be able to have access to ~4 minutes of music or voice wav. If there was some form of compression used like mp3, 16 minutes of sound.

[pirx]

Hi!

 

Thanks for the information.

What I am specifically interested in is how many colour changes per scan line are possible. More than with stock proc, that's for sure, but what I'd love to see is number of possible writes to, e.g., GTIA per scan line. This is especially interesting as the hardware access is not accelerated, I reckon.

 

Best,

 

pirx

[TXG/MNX]

Nice what when screen are compressed what framerate could be get ?

[drac030]

pirx: this number may be difficult to estimate. Here is my understanding of the matter:

 

The CPU runs at exactly 20 MHz (20000000 Hz = 1280 clock cycles per scanline), while the motherboard is clocked at 1,773 MHz (in PAL systems). 20 MHz is not divisible by 1,773 MHz, therefore an access to the "old" memory or I/O registers, besides the usual issues with Antic periodically intervening there, each time needs the two clocks to be synchronised by an appropriate number of waitstates on the CPU, executed until the appropriate edge of the 1,773 MHz clock comes in.

 

The immediate effect is that e.g. STA $D01A varies in execution time, its minimal duration being around 11 clock cycles (of the 20 MHz clock), and the maximum being about 33 clock cycles. The average is about 22 clock cycles, but in fact the periods vary as I wrote above, so changing a GTIA colour register you will probably get stripes of different width, and some trickery may be needed to get the whole thing synchronised well in each scanline.

 

PS. It must be said that I am speaking about the turbo mode. In "slow" mode the timings are the same as on a stock Atari.

Edited October 27, 2014 by drac030

[pirx]

Thanx drac030, that's exactly what I was curious about!

A great piece of hardware it is.

[ricortes]

Unfortunately when the screen is on the system will have to run at 1.79 MHz<or pal clock for Europe>. GTIA/ANTIC become the limiting factor in just how fast you can bang on them. The [better instruction set, fast mode during VBI, more code in DLI, ...] may mean some of the P~AL demos that break on NTSC may actually work.

 

As usual I could be wrong in my assumptions, but I think the 816 uses a toggle system similar to what we do now with 130XE except of course the processor does all the translation to what memory you want to address. What should happen is what ever memory the processor is accessing, ANTIC/GTIA will follow that with high memory lines in the toggle state and ANTIC/GTIA chugging through their limited address range oblivious to A16 up address lines states. Hmmm, clear as mud. It may be possible to do things like have an editor, debugger, and compiler, in memory at the same time and just do some simple task switching. Have an editor loaded in standard memory, a compiler and RAM mirror of OS at an arbitrary higher memory location above 64k, and switch between them. They would each have their own stack and page zero so they wouldn't go stepping all over each other. 15megs/64k => you could load ~230 virtual machines.

 

I don't know how it is done here of course, ANTIC/GTIA may be forced to only see memory below 64k.

 

It opens a lot of possibilities though. I remember Charles Brannon said Speed Script was ~flat out as fast as it could go to refresh the ~1000 bytes of display during the VBI. It should be trivial to handle 10 or 20 times that amount of processing. Maybe add a print spooler or something. *BUT* we probably wouldn't do anything that clumsy. Just toggle a couple of bytes in the display list or high memory lines.

 

Of course I wish the stock graphics could be improved a little bit too. The up side is in playfield mode of ~1000 bytes per screen, you should be able to do an hour of video. Think of PacMan attract mode that runs for an hour w/o repeating a single screen. Probably enough room to make your own cartoons complete with digitized sound. Digitized talking comic books, that kind of stuff. With a stock Atari something like ST class graphics 320X200 in 15 colors, was kind of too much for an 8 bit processor to handle. Sucked up too much memory and took to long to toss around. Extended memory and a 20 MHz 65C816 is a different story. In high speed mode, should be close to 4x the processing power of an ST. Since you need about 5 times the processing power to emulate a different processor, you should be able to emulate an ST with an 8 bit. That would be pretty sweet IMHO. Kind of a pipe dream though. Maybe in 2025 if we are still around. hehe

[flashjazzcat]

I remember Charles Brannon said Speed Script was ~flat out as fast as it could go to refresh the ~1000 bytes of display during the VBI.

I don't want to go OT, but I find that interesting. I typed in SpeedScript and the screen refresh runs in the mainline code. Or have I completely misunderstood?

[drac030]

As usual I could be wrong in my assumptions, but I think the 816 uses a toggle system similar to what we do now with 130XE except of course the processor does all the translation to what memory you want to address. What should happen is what ever memory the processor is accessing, ANTIC/GTIA will follow that with high memory lines in the toggle state and ANTIC/GTIA chugging through their limited address range oblivious to A16 up address lines states.

That solution would not be much practical, IMHO. Anyway, it does not work so. The Rapidus board goes into the CPU socket, so the additional 16 MB memory space (RAM, ROM, extra registers) is only visible to the 65C816 CPU. The traditional chips (Antic, 6502 et consortes) can only see the traditional memory, i.e. not only the first 64k, but also only what is present on the Atari motherboard.

 

It opens a lot of possibilities though. I remember Charles Brannon said Speed Script was ~flat out as fast as it could go to refresh the ~1000 bytes of display during the VBI. It should be trivial to handle 10 or 20 times that amount of processing.

An estimate of 16 KB per VBL looks reasonable as a maximum. Please remember that the display memory (including VBXE memory) is "slow", it can only be fed data at 1,773 (or 1,79) MHz clock rate, plus there are delays needed for clock synchronisation etc.

 

I do not remember the exact numbers at the moment, but the rotozoomer.pl (presented above on one of the films) requires a 12 KB frame buffer (in VBXE memory), there is ~40 fast clock cycles of calculation between pixels being drawn, and as a result one frame is drawn in ~1.5 VBL. That is for a practical example.

 

Of course I wish the stock graphics could be improved a little bit too.

VBXE (with the FX core) is an excellent improvement and it does cooperate with the Rapidus board.

Edited October 28, 2014 by drac030

[pseudografx]

How about a hypothetical case when you have display DMA turned off (559,0) - in such case, could you generate a nice colourful image just by quickly changing COLBG?

[+bob1200xl]

Why don't one of you wizards write a little routine to test just how many color changes (or, whatever) can be done?

 

Bob

[danwinslow]

confused a little bit about this colors topic - you can't just start jamming antic with changes faster than it can process, can you? Wouldn't you be trampling all over the bus?

[ricortes]

confused a little bit about this colors topic - you can't just start jamming antic with changes faster than it can process, can you? Wouldn't you be trampling all over the bus?

 

Thanks to Drac's explanation, I think this is substantially correct. The standard Atari chips, memory, ANTIC, PIA et al, will only do 2 MHz max. The consequences of doing it anyway but the way it is being done would have negative consequences. For instance, you would have to disable all the built in RAM on 130XE which aren't socketted and/or cutting traces in order to have the system see fast RAM in the first 64k. Cutting 16+ traces or removing 16 dynamic RAMs is not on my fun or good idea list.

 

Some of the stuff only time and experimentation can tell. For instance, you may be able to use the '816 built in memory move instructions to change all the color registers on the fly even at 1.79 MHz faster then has ever been possible. Some of Bob's early 80 column hacks and current Arduino hacks just use a fast clock for dot clock and a ~74LS166 to generate a VGA text screen display. Bob also did a dual display processor where he sync'd two Atari displays, each with their own memory, and combined them into the Atari's video circuitry.

http://www.freetronics.com/blogs/news/9133079-generate-arduino-video-output-with-80x25-text

 

The consequence of having a 20 MHz clock available as a dot clock and an '816 available means you could eliminate the ATmega328 and just add the 74ls166 with a couple of passive components. Instead of classic banging on the chip, you may be able to just give the '816 an 80 byte move instruction for each scan line to the parallel to serial converter somewhere in the memory map and have it handle the rest. Cheap <$50 80 column on either a standard Atari monitor or VGA screen. Kind of a reach for now w/o hardware in hand but most of the stuff is already out there in working form. There's no telling if it will be done, but it could be done.

[Xuel]

confused a little bit about this colors topic - you can't just start jamming antic with changes faster than it can process, can you? Wouldn't you be trampling all over the bus?

 

Small correction: GTIA holds the color registers, not ANTIC.

 

I think the idea here is that you could update one GTIA register with a new value at every tick of the 1.79MHz main clock (minus DRAM refresh cycles and DMA cycles) assuming that the code and data fetches happen in fast memory and just the stores are synced with the main clock. So the main bus will have a write on it every cycle. Contrast that with a normal 6502 system where load/store takes several cycles.

 

There are 114 cycles per scan line minus 9 for DRAM refresh and around 40 for DMA so you could theoretically squeeze in around 65 color changes per scan line, but a lot of those would be in the borders or HSYNC.

Edited October 28, 2014 by Xuel

[ricortes]

I don't want to go OT, but I find that interesting. I typed in SpeedScript and the screen refresh runs in the mainline code. Or have I completely misunderstood?

I'm not sure if I still have the book, bought it so I wouldn't have to type it in! You are likely correct. I may have lost context over the years, I'm not exactly sure of the technique he used i.e. DLI, display kernal, et al. I only remember the ~running out of processor comment he was quoted as making. Could have been for the what is a rock steady display even when scrolling vs. a glitch here or there.

[flashjazzcat]

I'm not sure if I still have the book, bought it so I wouldn't have to type it in! You are likely correct. I may have lost context over the years, I'm not exactly sure of the technique he used i.e. DLI, display kernal, et al. I only remember the ~running out of processor comment he was quoted as making. Could have been for the what is a rock steady display even when scrolling vs. a glitch here or there.

Yeah, maybe he was just trying to get Refresh to run in the space of a single frame or something. The editor loop just called it as and when after every keystroke. A split buffer would have made it twice as fast. Good little WP though, and formed the basis of TextPro.

 

[/OT]

[+Larry]

I'm not sure if I still have the book, bought it so I wouldn't have to type it in! You are likely correct. I may have lost context over the years, I'm not exactly sure of the technique he used i.e. DLI, display kernal, et al. I only remember the ~running out of processor comment he was quoted as making. Could have been for the what is a rock steady display even when scrolling vs. a glitch here or there.

 

Hi Ric-

 

A teeny-tiny question... Did the book come with a disk? I bought the book, but no disk, so I don't understand how that would save you typing it in? Perhaps ordering the book allowed you to buy the disk?

 

-Larry

[+Allan]

 

Hi Ric-

 

A teeny-tiny question... Did the book come with a disk? I bought the book, but no disk, so I don't understand how that would save you typing it in? Perhaps ordering the book allowed you to buy the disk?

 

-Larry

Do you mean this program?

 

http://www.atariarchives.org/speedscript/

 

Allan

[flashjazzcat]

I'd say I learned more about 6502 from typing in SpeedScript than from any other source. Recommended reading for anyone who wants to learn how do develop a practical application.

[+Gemintronic]

I'd say I learned more about 6502 from typing in SpeedScript than from any other source. Recommended reading for anyone who wants to learn how do develop a practical application.

 

Holy hardcoded values batman! That looks awesome!

http://www.atariarchives.org/speedscript/

[ricortes]

I'd say I learned more about 6502 from typing in SpeedScript than from any other source. Recommended reading for anyone who wants to learn how do develop a practical application.

 

Ditto. The program was just crazy good with techniques. Everything from replacement DUP, CIO/XIO, BCD mode, replacement keyboard click, calling the FP package... I spent an hour this morning looking at the code again!

 

Larry, just about positive I got the disk separately. There was a Compute blurb on ordering the disk in the book and maybe in the magazine. I *think* I got the book at B&C and they may have had the program/disk on the shelves too.

 

Flood of old memories. I don't know if they are common to everyone. Back then there was Luddite<grin> type reaction from most corners over dot matrix printers. At work everything had to have the each draft on a typewriter or Daisy Wheel printer because the suits thought dot matrix was 'too hard to read.' My kids teachers also demanded no dot matrix printers, typed or longhand. This was when the proles hadn't caught on to telecommunication so we still wrote letters. So I took a ski vacation to Jackson Hole Wy and met a teacher. Armed with my OCD I used Speed Script with an Atari 1020 printer to write to her weekly for a year or two Of course she probably thought the 1020 output was worse choice then a dot matrix or my chicken scratch handwriting. I just mention this in case anyone thinks I am unaware of being a goose.

 

And now back to our regularly scheduled program.