All Activity

The "sta (ind,x)" and "lda (ind,x)" were actually the easiest to handle. The zero page indirect address was set up to write to locations $1900 (top left pixel) and $ffff (bottom right), so that was easily mapped to VBXE address space. I set up 4K VBXE banks so the high 4 bits of the Missile Command arcade code address actually becomes the VBXE bank that I'm using. The low 4 bits is ORd with the address of VBXE video RAM bank (in my case from $2000-$2fff in regular Atari memory). So, for example, writing to Missile Command memory address $7654 turns into setting VBXE bank to $7 and writing to Atari memory address $2654. It works well, but the first pass I wrote generic routines to map and pixel read or write to the appropriate VBXE location and it ran REALLY slow. I had to optimize reads and writes to check for bank changes as efficiently as possible to allow for the final speed to be fast enough to not blow 60Hz frames. The actual Missile Command code rarely uses the 3 bit color lower screen RAM that is used for the bottom 32 scan lines (cities and scrolling text). I had to almost completely rewrite the scrolling text routine but even though I took advantage of the fact that the VBXE bank never changes, it was still too slow (the original code manipulated 4 pixels per byte whereas my code had to manipulate 1 pixel per byte, so it was slower). I ended up using a VBXE blitter to scroll the text (copy pixels 1-255 to pixels 0-254 with the blitter and then fill the last column (255) with the background color). I also used blitters to quickly clear the screen and lines of text. The sound does seem perfect to me and I've played a lot of Missile Command. The original hardware is interrupted at 240Hz to handle precise trackball reads and update POKEY. I ended up using a very low resolution 40x24 graphic mode just to set up VBIs to handle more trackball reads and handling POKEY sound updates for planes, satellites, and smart bombs - those needed 4 updates per 60HZ frame. The rest of the sounds worked out by just calling the routine to update the sounds 4 times within the VBI rather than once every 240Hz.

I noticed what look to be disassemblies of all three Thorn EMI cartridges in there. I saw a note in the Computer War (high) file that you had relocated it--I take it that this change moved it out of 32K space and into cartridge ROM space. If so, that explains a lot about how MicroPAL was able to release that title as a standard cartridge (but kept the other two running out of expansion memory).

Am I the only one who saw the two cool Easter egg buildings? One had this one it: HSW WSH The other simply said "Nolan." Nothing like cool shout outs to Howard Scott Warsaw and Nolan Bushnell. As for the game, it looks like it could be fun. I'm not big on platformers, but I'll check it out for sure when it releases.

Did you by chance install one of the DC-DC switching regulators into it? One thing I didn't mention, is that even though the Tracos I use are supposed to have filtering caps in them to reduce or prevent switching noise...it still causes the interference like you are talking about on RF output when I've installed it into 7800s. However, since those consoles also get a UAV, the switching noise doesn't show up on the composite and s-video output since the UAV is able to filter everything out using a separate encoder as it does. One thing that I've done in a few cases where I noticed it was more obvious than I would like is to add a 220 - 330µf 25v cap off the input and ground from the switching regulator. Just to try and smooth it out more. Not my idea, but it was something I noticed Tim Worthington included in his RGB kits for the 2600 and had as part of the required install process. This was because due to the extra load of the RGB boards, Tim included a dc-dc switching regulator to install to drop the current requirements of the 2600 so that even with the RGB board in place, the 2600 only required about 320mA of current. That meant that owners installing the kits didn't have to get beefier PSUs since the stock adapter with its 500mA output rating was still adequate. Anyway, just something to maybe try and see if it helps if you did add one in. Sharp eyed folks might see one attached on the bottom of the main boards for pictures I've posted on some I've installed where the RF was still being used.

🤡

It's nice to see this got a release. I picked it up on the VCS, of course. I did that for two reasons. First, I bought it on there to support the VCS. Second, I was one of the people saying it needed to come out on the VCS, so it wouldn't have been right to buy it on anything else, since Atari obviously listened to us. A lot of companies are deaf to what their customers want, so I like to reward those companies that actually listen. As for the game, it's super fun and frustrating as heck. But, that's how you know it's Lunar Lander. 😂 The graphics are top notch, as is the sound design. The fact that it's fully voice acted is also a nice touch. I too would have liked classic joystick support, but I suspect that wasn't added due to the classic joystick not having enough buttons for the game. But, I also have no issues using the modern controller. I'm just glad this game came out on the VCS. As for the price, I personally think it's worth it for what you get. As I said, it's got voice acting, that's not cheap to produce. Neither is that animated intro. The graphics are also higher quality than games like the Recharged series. But, I can also see the point of view of the people who say it's too expensive. For one thing, it's one of the three highest priced games in the VCS store. It's tied with the Atari 50 collection and Days of Doom. And, with Atari 50, you not only get a lot of games, but you also get the wonderful timeline history of Atari which, in my opinion, is worth $30 on its own. And, of course, Days of Doom is an RPG. A lot of people probably equate Lunar Lander Beyond more to the Recharged games, which are $10. Thus, they probably think 3X that is high for what you get. Though, to put it into perspective, I was happy to get two XBOX games on sale for $35 on Steam last weekend. Yes, those were AAA titles and one was an ultimate collection with most of the DLC, but $30 is still inexpensive next to games on other systems. And then, after paying $60 to $70 for a game, you find out it's not a complete release when they start releasing DLC. Compared to that, the VCS formula of releasing complete games for a decent price is one of the most attractive things about the system, in my opinion. Right now, a lot of big companies are doing some shady stuff with their games, and consumers are eating them up, (yes, I'm one of them) so there's no reason to stop. Compared to them, I like Atari's way of doing things a lot better.

Hi, Yes, ok now I get it man its been decades ago I coded ..... Now also figure out the right syntax to get the start memory address of the array...

Thank you Colin, as usual your vast archive of TI history and making it available to us is greatly appreciated.

560/561 points to the display list. You need to change the display list itself to point to your own screen Ram. In most cases display list + 4 will be what you need to change.

I am confused here when I read my array and poke that directly to screenmemory I dont have to change 560/561 var sc : word absolute 88; for i:=0 to 959 do begin poke(sc+i,screendata[i]); end; So this copies data from array to the current screenmemory. How is it impossible to point screenram to the start of an array ?

Damn, I was hoping for a spiritual sequel to one of his other games, maybe titled "Generic Non-Spielberg Space Alien"

Didn't Scotty invent transparent aluminum back in 1986? It seems to me that would be the best solution in recreating the 800's metal shielding to be able to see straight through a clear case. 😁

Location 88,89 is just the pointer to screen Ram that the OS refers to when doing character writes or pixel plots. There's also the actual screen addresses fetched by Antic which are in the Display List and you'd need to change those also. Typical Display List (560,561) will contain: 112 (3 times) 8 blank scanlines 66 LMS Antic Mode 2 (Gr. 0 ) low byte screen Ram high byte screen Ram 2 (23 times) 65 (Jump and wait for VBlank) low byte display list address high byte display list address You'd also need to ensure the screen memory doesn't cross a 4K boundary - without another LMS Antic will just wrap around and read from the current 4K block start.

I've designed a multibank card for my COCO2 and I tinker a bit with drivewire. I've flashed "HDB-DOS 1.1D DW3" in one bank of my card and got it working, but I also have some instabilities. Sometimes the computer freezes when loading a game and I need to go through a power cycle to bring it back and then the same game can load wihtout an issue. I have a jumper to enable /disable autostart, I will give it a try. However I'd like to know where I can find the latest HDBDOS version for Drivewire. I've been following the links from here and only found v1.1d : https://www.cocopedia.com/wiki/index.php/Getting_Started_with_DriveWire

How long did it take to make the Colecovision DK? Because if it took a lot longer than 90 days, and could afford a ROM larger thank 4 or 5 KB, then it sounds to me a lot like “never mind the budget — make sure ours looks and plays better than the others, whatever it takes!” sort of situation. In that view, the programmers for the other consoles may not have been asked specifically to make crap games, but that sounds like a distinction without difference. dZ.

Does that mean Yars' Academy is planned for the VCS 800?

I believe there is a bipolar 1uf cap in the reset circuit. If it's a reset issue, replacing that may fix it.

It looks like it may have come apart some.

I won't argue with the fact that Wolfenstein 3D looks awesome on the Jaguar. I had two games on my Jaguar, Wolfenstein 3D which I liked and Cybermorph which was garbage. My problem with the Jaguar is not as such the specs of the system but the lack of third party support for the console. Also from the few games that actually made it to the system almost none of them took advantage of the claimed 64 bit power. Games on the Playstation and Saturn, both 32 bit albeit released after the Jaguar look better. Heck, most Jaguar games don't look much better than similar games on the 16 bit SNES. So no matter what the hardware can do, without decent 3rd party support its bound to fail. Same with the Atari Lynx, a portable which holds very dear to me because it was my first handheld. It was technically superior to the pea green Gameboy or even the Game Gear and had a few great games which I already mentioned, it also has a lot of crappy games. I don't care for the recycled old Atari arcade ports they made for it just because it lacked support from publishers. Honestly, I am not an Atari basher. So much so that my first ever computer was a 65XE and I have fond memories of playing games like Henry's House, Pac Man, Mario Bros, Pitfall etc.

It's not necessarily a bad thing to have third parties develop your games, but you get the quality that you are willing to pay for. A lot of XEGS games were disk games ported to cart.. cheap! Even today a lot of exclusives are developed by third parties, and sometimes those studios are bought by the platform holder if they do good work. Atari today has been doing that, but back then I don't recall Atari buying any game studio back then. Epyx would have been a good purchase and fit for them, certainly better than the money Atari wasted buying Federated or Abaq (the Transputer workstation)

Hello, I have a few screens embedded in my code. Those are array's of bytes. I would like to switch between the array's on graphics 0 and not copy the data to screenram but point screenram to the begin of the array. array1 ... array2 .... p:^înteger; InitGraph(0); p:=@array1; I did try dpoke(88,array1), dpoke(88,pointer(array1)) and dpoke(88,^array1) and dpoke(88,p) maybe its just syntax but whats the way to do this ?

I'm going to wrap up my repairs with one final saga. I was always seeing diagonal noise in the RF output no matter what I tried to cut out interference (cables, power, room location, thoughts and prayer, ...) . This lead me to rigging up a simple composite mode (the few resistors + cap + 2n3904). Composite has significantly less random noise, but the diagonal banding persisted and because of the cleaner picture the banding, in my opinion, was much worse. In the end, looks like I have a very noisy TIA, and specifically the Tsync from Pin 2. 1) First problem is that when playing 7800 games the Tsync line would only decrease in amplitude to about 0.8V, which is right at the cusp of TTL logic and may causing problems with U3. So I added a resister to drop the peak-to-peak down to 0.4 V, but still keep a valid Tsync range for 2600 games. 2) Second problem was a ~0.5Mhz ripple on Tsync when the signal is high and was polluting the 74LS32 (U3) signal. After some experimentation, I found that tying a 10 nF cermanic cap to ground from Pin 3 of U3 filtered out a large portion of the noise. It was definitely a journey, but I'm quite happy with the result. There is still some minor (very minor) flicker left that I'll likely tune out with additional caps (looking at Pins 6, 8 and 11 on U3). This 7800 definitely has it's own character but I believe it's been tamed.

I've managed to get my ASR733 system working and extracted quite a few 99/4a files that may be of interest - in particular the DSR descriptions mentioned above some time back. https://www.blunham.com/Misc/Texas/Mine/index.html Colin Hinson.

😎 102 550 Should’ve been a much better score, had three lives and over 100k going into the meteors and it was brutal, no way through on the first life, dead before making it down the screen on the second and two close calls and death shortly after. I started a couple of games resuming that level afterwards and made it through there clean every time! My controller is getting worse too, stuttering and more wild movements, like taming a stallion!

“I hate asparagus, but I don’t talk about it on asparagus.com.” - Shawn Drover