Chilly Willy

Yeah, there were schematics in a couple of magazines at the time showing how to make the FSK decoder so you could use any cassette player on the Atari. It wouldn't be hard to alter the filters to allow a higher frequency, but the filters Atari used could be fudged a bit. Atari chose the low rates/frequencies mainly so that unusually slow or fast cassette hardware would still work. Tolerances on the drives of cassettes were notoriously bad unless you paid twice as much for the hardware. That was one of the nice things about peripherals on the Atari - using a "standard" async serial port allowed for a LOT of flexibility on cassettes/floppies. Cassettes just needed an FSK decoder on the input to the computer.

Most folks probably remember ROQ from Quake3, although it was also in a couple other games. Quake3 videos are [email protected] ROQ was never patented, and there's been an open source encoder for many years, which eventually made it into ffmpeg and libav some years ago. It's easy enough to transcode video into roq... here's some lines I used for transcoding Cowboy Bebop: [email protected] - Q=14 ffmpeg -i Cowboy_Bebop_01.mkv -c:v roqvideo -r 24 -q:v 14 -vf scale=288:208 -map 0:0 -c:a adpcm_ima_wav -ar 22050 -ac 2 -map 0:2 CB01_r24_q14.avi [email protected] - Q=1 ffmpeg -i Cowboy_Bebop_01.mkv -c:v roqvideo -r 12 -q:v 1 -vf scale=288:208 -map 0:0 -c:a adpcm_ima_wav -ar 22050 -ac 2 -map 0:2 CB01_r12_q1.avi You can do cinepak by simply changing the video codec from "-c:v roqvideo" to "-c:v cinepak". The quality constant is not the same for both other than 1=best and 31=worst. 12/15 Hz videos can be 1 to 5 and fit in a 1X CD rate, while 24/30 Hz will be 10 to 15. Note that you need a version of ffmpeg that is newer than 14.0 to have the cinepak encoder, which was added in Jan 2014. I'm trying to keep my frame sizes less than 128KB for 16 bit RGB since that's what the 32X has. For better consoles like the Jaguar, I can go to slighter higher, doing 320x224 for 4:3 videos (NTSC). I use 320x176 for 16:9 for everything since that fits in 128KB just fine. For ROQ, you need to keep videos to a multiple of 16 in both dimensions since ROQ uses 16x16 pixel macroblocks. Cinepak uses strips of 4x4 or smaller blocks, so cinepak needs to be kept to multiples of 4 in both dimensions. Cinepak and ROQ both give similar results at about the same bitrate, with some videos maybe favoring one format over the other slightly. Cowboy Bebop looks a little less blocky on ROQ. Perhaps the biggest difference between the two is the player code license - all cinepak player code (I have seen) is LGPL, while ROQ is all variations of BSD. So if you are working on closed source, ROQ is your choice. If it doesn't matter because you are making it LGPL compatible open source, you could use either one.

Hahahahahahahahahaha! Oh god! You're killing me! Okay, point me to these $500 X68000s that I might buy five or six of them.

BasiEgaXorz: http://devster.proboards.com/

Not quite... just like the floppy, the cassette allowed for having blocks which could contain code that could be called. I commonly added a block to my cassettes that turned off the noisy bit so that the cassette was quiet. The only thing hardcoded about the Atari cassette were the frequencies used by the FSK in the cassette. The default loader in the rom was pretty quick - almost as quick as the default C64 floppy! But you could always load some code to the start to replace the rom code, as Yautja pointed out.

ROQ format is pretty simple, and could easily be accelerated with the blitter. It's mostly copying small blocks... the screen is split into 16x16 pixel macroblocks. Each macroblock is always split into four 8x8 blocks. At that point, one of three things occur: the 8x8 block could be copied from the previous screen +/- several pixels motion; the 8x8 block might be drawn using a scaled up 4x4 block from the 4x4 codebook; or the 8x8 block may be split into four 4x4 blocks. Each 4x4 block may have one of three things occur: it may be copied from the previous screen +/- several pixels motion; it may be drawn from a 4x4 block in the 4x4 codebook; or it will be drawn using four 2x2 blocks from the 2x2 codebook. The N64 is a 94MHz MIPS, and can handle all that in plain C code in real time for low res video (320x240-ish) up to 30Hz. Decent GPU assembly + BLITTER acceleration can probably handle the same thing. This is one of the things I'll be playing with this winter on the skunkboard. Get it working on small clips in rom to start, then work on a streaming version.

Neat! I'm sure some folks would love that... me, I'm in the "hate the EA cart" camp. When I need a Sega cart case for something, I just hop on ebay and get another "throw away" NBA Jam cart.

You'll have to provide some examples of that as I had Necromancer on cassette, and it loaded a HELL of a lot faster than that! Basic games on cassette were slower than binary games because Basic used "slow" mode - they had a long pause between sectors on the cassette to give the slow Basic a chance to deal with the data and still get the next sector.

Technically speaking, any system can decode full h.264 HD... just not in real-time. If you're talking about real-time video on a console like the Jaguar, you've really only got two realistic choices: cinepak, and roq. Both can be encoded by FFMPEG, and decoder source is available. I recently made a ROQ player for the N64 to get an idea how well it works. I'll probably try my hand at that on the Jaguar once I get all the dev tools worked out.

Yeah, the price was why my brother got it - it was all he could afford. I got a job at a TV repair shop to buy my A400. As to the topic, I can't stand how slow the C64 floppy and cassette are. Seriously, my A410 was faster than the C64 floppy! Anywho, the C64 traded slightly better sound and graphics for processor speed. The Atari runs rings around it due to how they implemented the bus sharing and DMA.

My brother got one of those. My Atari 400 made it look like shit. He eventually got something better (an 800XL) and was going to throw the Timex in the trash, but I paid him $5 for the thing and all the extras he had... including that crappy 16K expansion. From an engineering standpoint, it was a really neat piece of hardware. From a user standpoint, it was trash.

Simple protection like multiple sectors with the same id or the like was trivial. Tougher methods like strong bits or weak bits required a little more hardware. A few companies made little carts that plugged into the port on the back of the Amiga with pass-thru for an external floppy that allowed the tougher schemes (including long tracks) to be copied between two floppies. These carts basically fed the read data line of one floppy straight to the write data line of the other floppy. You then turned on and off one of the drives until the index markers synced up and activated the switch for a track. Getting the drives in sync was the fun part - depending on how close the drives were to each other in speed, that was sometimes not possible. You'd have to find a pair of drives that would sync to make copies.

Given the setting he mentioned, the bitrate is with audio + the overhead of .mov container. The theoretical limit for 1X CD with ECC is 1228.8 kbps, and the Jaguar CD is 2X and doesn't use ECC, making the limits even higher. The settings did indicate he was using the truecolor version of cinepak. Maybe the Jaguar player only like the 8-bit paletted version. EDIT: The Jag cinepak readme says 16 bit rgb or cry format.

It's not the drive hardware that's different, but the floppy controller. PCs use a "standard" IBM style FDC chip that is designed to read/write MFM one sector at a time, one byte at a time. The Amiga reads/writes the entire track at once, so they decided to make it work on words in the sectors so as to allow using the blitter to decode/encode the MFM. A scant few PC FDCs have raw track commands that allow reading/writing raw MFM, and those can read/write Amiga floppies just fine. Since the Amiga read/wrote a track at once, they didn't need to worry about sector gaps. With tiny sector gaps, more data could fit in a track, which allowed the Amiga better storage. Late in the DOS age, there were PC formats with more sectors per track with smaller gaps. This allowed more data per track than normal, but you could corrupt a disk by writing to it given the smaller gaps. These formats were meant for installer software where you weren't going to write to the disks anyway, and the larger storage meant fewer disks for the install. CDs quickly supplanted this format as people would rather deal with one CD than 6 to 10 floppies. Some Amiga games did away with the standard track format, knowing the Amiga read tracks all at once, they simply made the track one huge sector. Pysgnosis was famous for this. They also knew that Paula could track a small change in speed from the normal, so they wrote the track at a slower speed to fit more on the track than was possible writing at the standard speed (thus killing the ability to copy the disk without special hardware). Their "standard" length was about 20% larger than a normal AmigaDOS track.

Maybe turn that into a one-page PDF for printing out? That would be handy to have on hand while working on those old systems.

If you have an older computer sitting around doing nothing, you might try installing something like Ubuntu on it and using it as your dev system. JCP works fine in linux,even the very latest version. Really old Jaguar tools work with DOSBOX, and newer Windows tools can be run with WINE.

How about using the SELECT button for switching? Those console keys tend to be ignored by most interfaces.

On my old A400, I just booted Pitfall II and turned the pot until the screen matched the screenshots on the box.

That's 50% of the CPU slots. Remember that the CPU takes four cycles to do a read or write, with the actual data being read or written in the last two cycles. The chipset always takes those first two "free" cycles, so the CPU has 100% of the slots it's CAPABLE of using free as long as the chipset doesn't take any of those slots. Five bitplanes (low-res) takes 25% of those slots, and six takes 50%. High-res bogs down more as 3 bitplanes takes 50% of those slots, and 4 bitplanes takes 100% of those slots. That's why stock Amiga 500s and 2000s are so effing slow in 16 color high-res - you only have free CPU slots in the blank periods when running in chip ram. That's why they recommend getting fast ram for your old Amiga. They used whatever memory was cheapest to get in bulk at the time the assembly plant needed ram, but 150ns access time was plenty fast. Remember that the chipset was designed to be a console in 1983. There's no way they would have designed it around 80ns ram. The chipset uses two CPU clocks per cycle for all memory access operations. All COPPER timing is around that frequency. The chipset always has priority over the CPU when it needs more of those two-cycle slots. The BLITTER has a bus hog setting that can lock the CPU entirely until the blit is done, but most folks didn't do that. All this is in the various hardware books Commodore put out. I've got them all. You can also find these hardware manuals online in various formats. AGA changed this timing in two ways - first, they added what was called Double-CAS mode - they did two page mode reads in the same amount of time as one normal read, or one read per clock cycle (the 68020 ran at 2X the clock cycle, or 14.4 MHz). The also had Double-Wide mode, which fetched 32 bits instead of 16 bits. You could set either mode independent of the other, and one or the other or both were needed in order to fetch enough data for AGA modes. For example, the sprites normally fetch one word per access slot per bitplane per line. An AGA sprite would run in Double-CAS/Double-Wide mode to fetch two longs per bitplane per line, allowing sprites to be 64 pixels wide instead of 16. Likewise, switching to a faster fetch mode allowed low-res displays to show 8 bitplanes (or high-res to show 4 bitplanes) without using all available memory access slots like under the old chipset. High-res 8 bitplane still took all access slots. The new SuperHiRes mode (1280 wide instead of 640) took all access slots at 4 bitplanes even with the faster fetch mode.

The 68000 uses 4 clock cycles for a read or write cycle. That WOULD be ~560 ns, however, the 68000 only actually uses the last two cycles of the four to read/write the data. So the Amiga chipset was designed to use the first two cycles, leaving the next two free for the CPU. That theoretically made the CPU run at full speed while the chipset was active. However, not all 68000 cycles are multiple of four, which adds a two cycle wait to some instructions, and the chipset needs some of the CPU slots to do other things - in particular, more than 4 bitplanes in low-res mode, or more than 2 bitplanes in high-res mode can steal CPU slots. Anywho, a slot is therefore two cycles, or about 280 ns... VERY cheap memory. That was also one of the reasons Sega used the 68000 for the Genesis - really cheap slow roms. In fact, the VDP DMA on the Genesis is faster than the 68000 bus cycle, so it fails on old (slow) roms if you try to DMA directly from rom. Sega recommended copying/decompressing from rom to ram using the CPU, then DMAing from ram to vram. Newer carts were made using faster access times, so the game could DMA directly from rom to vram.

It would be nice if a touchpad could be used with a mouse... the pad draws in a limited range, while the mouse is used to pan around the larger image. But that would be part of a drawing app, not this OS. If I were supporting a pad in a GUI, I'd probably use the center part of the pad to directly track a small area on the screen, while touching the outer part of the pad would trigger a "scroll" of the cursor in the direction you are touching.

Yeah, I use lz77 when I can. It's good on some things, but not really great on most images. Compressing is a bit slow, but decompressing is really fast.

Very good point. If you know the order the drive formats the track in and you know the amount of overhead used by your program + cio call, you can order the data in non-consecutive sectors to cover that overhead. Software interleave the data instead of hardware interleave. You'll need to make a command line tool that takes an input data file and an interleave value, and outputs a new data file with the interleaved order that you then dump to sectors on the drive. Then just try a range of interleave values to see what actually works best. If you have something like sio2sd or sio2pc, that wouldn't take but a day's work, if that.

He's not going to get ANYTHING for images with decent compression that will decode in one frame... that's the realm of video compressors where they compress over several/many frames to get the compression while being roughly fast enough to decode in one frame. If he wants that, he should be looking at cinepak, not any single image compression scheme.

You might consider ELM's Tiny JPEG: http://elm-chan.org/fsw/tjpgd/00index.html It can decompress to RGB565, so it shouldn't be too hard to rewrite for other 16 bit modes.