DamageX

It's a 32-bit DOS command line program, and should work in any 32-bit Windows. Not sure about Win 3.1 or 64-bit.

Using a ratio of the color burst freq for the pixel clock was very common. 3/2 - TMS9918, NES/SNES, SMS/MD, PCE, Yamaha V99x8 7/4 - NeoGeo? 15/8 - MD, Jaguar, Saturn 2/1 - PCE, Saturn 3/1 - V99x8, SNES, PCE 15/4 - Jaguar, Saturn 4/1 - Saturn

An 800XL just appeared on the Colbert Report (suggested for avoiding NSA surveillance).

I'm sure it's because chicklet keyboards are fashionable again. (nevermind that they weren't actually fashionable back in the day, just cheaper than real keyboards...) lulz

I liked this document: http://www.dwheeler.com/6502/oneelkruns/asm1step.html

now that is one seriously awesome hack.

Freescale (formerly Motorola) 68HC08 microcontrollers are still around and they are as similar to 6502 as anything. NASM supports AMD64 instruction set.

I don`t know the BITS author, but apparently he has a record of entering these eccentric demos in various competitions. And yes, the chorus of random sound effects is by design.

:trollface:BITS1508 was just released... see here http://thebitsclub.tripod.com/

relaunched eh? I didn`t realize it was ever out of production. In this day and age, someone could manufacture 100 6502s at 100MHz, with 64KB of RAM each, on one chip. I often wonder about this when reading about the latest GPU that has 400+ shaders and 1 billion+ transistors on the die. 6502 doesn`t have floating point or even multiplication but surely there is something cool that could be done with a billion transistors worth of them running in parallel?

That was a 16-bit QuickBASIC program so it won`t run natively under 64-bit. Nowadays I am usually using FreeBASIC instead which compiles to 32-bit. I will have to convert it over sometime. BTW, ANTIC`s inability to increment the address past a 4KB boundary is annoying. Would it have killed them to put the whole 16 bits, or at least 13, into their adder? (I`m guessing the bad line bug is related to this)

I have the syntek 1150 based one. It works good in win2k and xp, as long as you have USB 2.0 ports. I use virtualdub for capturing. When capturing, make sure that "TV Tuner" is not selected as the source, because the device doesn`t even include an RF input, and furthermore in the USA at least there are no more analog TV broadcasts anyway. It`s also possible to use the "imaging" program that is supplied with win2k, or something like irfanview to take screenshots from the device.

well here`s a quick update, I`ve improved the scenary drawing routines and added code to control an NPC vehicle in the game. and I got a cheats file for MAME so I can map out the rest of the stages. slow but steady...

Love it. What`s the story with that nuclear reactor program? Just a demo, or a piece of educational software perhaps?

I also, liked the various noises that harddisks made back in the day. When your HDD LED was on 100% duty cycle, you could tell whether that was because of sequential I/O that was moving a ton of data, or a ton of seeks and not so much throughput. Now you need software to tell you that. Anyway, I still have some MFM 3.5" and 5.25" HDDs, but I can`t use them at all unless I were to whip out an old board with ISA slots and without on-board IDE, to use the huge "winchester" controller card that I have. Using MFM drives on the Atari doesn`t strike me as a good plan though. The drives are "dumb," so you need a real controller, not just an interface. Getting SCSI or IDE drives (which have a built-in controller) working on the A8 is already enough work.

Odd choices. 6502 and TMS9990 (and others...) were chips that had a real impact. Pentium and GeForce 6800, however different their internal architecture was compared to their predecessors, were still just incremental improvements of existing product lines. Also, no mention of ARM, NEC PC-98 series, or harddisk drives?

That has already happened. Video chips were desoldering themselves left and right on video cards, laptops, xbox 360, etc.

I think that will be necessary because midi files permit overlapping notes on one "channel." So even if there only four voices in a midi file you can`t always map them 1:1 with POKEY channels.

that is resize to 80x224, reduce to 9/128 GTIA colors with dithering and color changes allowed to occur before pixels 24,36,48,60,72 of every line.

Interesting idea, really could work with a PC tool created for that. That is no problem. For instance, I just converted this: to this: Someone else can write code to display it on the A8 though...

Yeah, I think you're right. Some bitplanes can be displayed at the same time, but the number of copper color changes must have been around 40 rather than 80 (copper would have to fetch an instruction word and data word for each color change)

On the Amiga the screen DMA is generally turned off for "copper chunky" modes and it just rewrites the background color register repeatedly. A8 could do the same thing with the CPU executing a huge lump of LDA #xx STA $D01A instructions but since a pixel would be 6 CPU cycles you'd only get 14 or so pixels per line. (on the Amiga it can do 80 pixels IIRC)

wow, exomizer compresses the files better than deflate? I will try to get this running in the ROM.

I want to compress the music data in the Outrun ROM to make some more room, then decompress into RAM when needed. Is there code out there already for this? Even a general purpose data compression routine would probably be fine if it is compact and has only a small memory requirement. Reinventing the wheel can be fun but may not be the best use of time, so I wanted to check first before I started on anything.

I have a 256KB upgrade plus the VBXE, for 768KB total. So I`m not itching for more RAM. I have the full DOS version of APE and hiassoft`s patched OS for booting at 3x SIO. But I feel like having to boot the PC and juggle disk images to use the Atari is still kind of a pain, and 3x SIO is still slow when it comes to loading VBXE graphics or sampled audio. There is also the issue of having to switch among various DOSs where some have better features but can`t run certain things because of the memory footprint or whatever. I was told that cartridge-based SDX manages to pack a lot of features while keeping a small memory footprint by taking advantage of the extra bank-swtiched ROM. Of course I have never been able to run it because I don`t have the cartridge. So what if we take the idea of a bank-switching capable flash cartridge and make it able to boot SDX, and throw in an RTC, as well as a CF or SD card interface? Then the A8 can be switched on without a bunch of external stuff attached, boot quickly to a good DOS and have a huge amount of software at the ready. Then it could be even better if we had software that was able to mount disk images contained in the A8 file system itself. "FAT" file system driver could also be helpful. This would be a similar setup to my MSX2 computer where I have a cartridge with DOS in ROM and an IDE interface so I can boot from HDD. Then certain disk images and ROM images can be started right from the command line, so there is little need to be dependant on an attached PC or on floppies.