Omegamatrix

Here is a perfectly aligned 36 character demo that is a mock-up for CDF or DPC+. After I made it I realized the irony that I am actually doing the display on stock hardware and that it is perfectly aligned. It uses immediate loads to mock the 2 cycle fast fetch loads that CDF and DPC+ do. This is not the droid I was looking for, but at least it proves the 2600 is capable of doing a perfectly aligned 36 character display on stock hardware. I do still believe the perfectly aligned 36 character routine in which the data can be loaded from zero page ram is accessible using stock hardware. That is the next bar to reach. Somebody will do it. With CDF or DPC+ 40 characters should be the target. I don't know if we can get there, but we should try. With bus stuffing it should easily be possible. 36_Char_201805013.zip

Thanks! I had a couple of vacation days so I played around and came up with this. I really do believe a properly aligned 36 character routine is accessible. I'm sure someone will do it, but I am out of time myself. It is just a matter of finding a combination of spacing and techniques that work. I've tried experimenting with VDELPx and 3 copies medium spacing as some techniques for example. The 'B' kernel I made had many cycles left, and the 'A' Kernel was completely full. It was full because I had one nasty spot where I was updating the graphics for GRP0 while the current sprite was still been drawn. So I had to do an extra hybrid write that had the trail end of the existing sprite, and the beginning of the new sprite. Even then I still had to use the ball to cover up one pixel. Incidently kernel 'B' is also the one with bad alignment so it would be nice if it could be fixed. However In the end I believe a perfectly aligned display will probably require two completely new kernels.

Here is a 36 character text demo. Check it out. 36_Char_201805011.zip

I got back to this today, and made a new kernel that flickers at 20Hz, but didn't do any overlap. I haven't been able to test it on real hardware yet. 160_Pixel_20180504.zip There are three rows, and the bottom row should be the clearest. Each row can display all 160 pixels over a few frames (4 for the top two rows, and 3 for the bottom row).

Here is a 160 pixel demo. I confess it does use flicker (a lot!). I always avoided using lots of flicker, but when I tried it out my LED TV it was surprisingly readible, which is why I'm posting it. In the demo are two rows of text. The bottom row in particular looked okay in my modern TV in its progressive mode. Here it is. If you are using Stella better ALT-P in Windows to enable phosphor effects. I would be interested in how it looks on real TV's and what sort of TV you have (CRT, Plasma, LED, etc...) 160_Pixel_20180429.zip

There is a way, but not without some tradeoffs. If you enable score mode in the CTRLPF register then the leftside playfield uses the color of P0, and the rightside playfield use the color of P1. However the ball still use COLUPF as its color in score mode. So yes you can do it, but not without tradeoffs.

When I first played the game I thought they were crabs. You know it's a 2600 game when no one is sure, and it's left to the imagination.

I think your Encore is 100% working, and the issues you are seeing are the fault of the game itself. In Porky's case it does not initialize correctly. I hacked one single bit to fix it. Porky's (initialization fix).bin Lot's of Atari games have various issues like this. Another common problem is finding some games will not be compatible with certain TV's, and they will roll.

One other thing, did you have the all in one Millipede? There is a version that has the auto-detection screen at startup (like in the picture you have posted of your TV above). As far as I know no one has tested it. That is the most recent version.

I believe the entire problem related to Millipede, Star Wars, and SpaceMaster-X7 is interferance with the AtariVox being plugged into the right port. I read that you said you needed it get your Atari working, but that is causing the issues here. I have tried these roms on real hardware myself, and they were fine. Please note that with Millipede the speed is halfed for the Y-axis as the area is very narrow vertically.

I took a quick peek. The difficulty switches are not used. Select or Reset will start a new game, but otherwise they are not used.

Please never mind the testing for now. I have learned more about early HMOVE's and I don't think just finding new values will solve all of the problems.

I made one blue darker. It is built from the 08-18-1990 NTSC proto. I didn't disassemble the game. I just used Stella and HOM3. The colors seem to be in two duplicate tables. In HOM3 one table is at $1E99-$1EA0, and the other is at $2A15-$2A1C. I think at least one of the lower bits (bit 1 or bit 0) must be reserved for making the block flash. To leave those bits alone I made one of the blues darker instead of brighter. Klax (color hack).bin

If you ever played an Atari game you've probably seen some little black lines on the left of the screen. One of the 'tricks' programmers use to eliminate this works on most consoles. The few consoles that do have issues with the trick might still be okay if the game runs a check and corrects the trick. In the folder are two test roms. Use the NTSC rom if you are in North or South America. Use the PAL rom if you are in Europe or Australia. The idea of the test is to let the program run on your system: - A green screen is normal, but If you see a blue screen then I am very interested in the numbers it displays. A photo would help here. - Watch the two two blocks at the bottom the screen. They should always be aligned to each other. If they are ever un-aligned then it is a failed test, and it would be important to note what number(s) at the bottom of the screen it fails on. - The blocks move quickly, but you can press the joystick left to slow the block speed and it eventually will stop. Press right to speed it up. The program goes through two loops of L1 to L15, and then two loops of the L0 value before repeating. - There is a small chance that the program will work at the beginning, but then the blocks become unaligned as the console warms up. Usually after 5 minutes it is fully warmed up. If you can please check the the program when first powered on, and then again after 5 minutes. Finally the consoles that I am most suspicous of (which will have blue screens) are some late model Atari Jr's, and maybe some 7800's. Any console testing is helpful though as I really can't say which ones are going to be different. Please state what your console is. Thanks for all those that help. DetectEarlyHmxx.zip

It would be interesting to see if the PAL version of Stargunner also has the same fault. I looked at the listed programmer, Alex Leavens. Several of his games also have other programmers listed, and those roms seem okay for the reset vector. Where it it gets interesting is the Bouncin' Baby Bunnies proto (also a Telesys game). He is the only listed programmer, and yep same fault of $0000 at the reset vector.

Just to be clear here, there are only 3 games CBS made with their extra ram: Mountain King Omega Race Tunnel Runner So please don't start talking about the SuperCharger, Basic Games, and the AFP as they have nothing to do with these games. The extra ram for these 3 games is stored on the physical carts, and we have demonstrated that this extra ram is not all zeros at power on. Randomized ram for CBS carts needs to be the default behavoir of Stella as it accurately reflects the real thing, and the real thing IMHO will always be a true CBS cart. As a developer following the correct behaviour of the real thing is essential. If I wrote a new game and had it put on an old CBS board, then I sure would not depend on the ram being zero. My game would fail and that would be foolishly my own fault, for not clearing ram. This is what makes Stella a great emulator. It emulates the real thing and helps the developer catch problems. Your games breaking in Stella are a problem. You just don't want to acknoweldge it is a problem, and instead want to say it is a problem with Stella. In fact Stella is the one that has it right.

Yeah, that is like the randomization I remembered when dumping Dig Dug. Certainly not all zero's, and changing.

This simply is not true for real hardware. We tested that and proved that. Please re-read what you quoted and concured to me here: http://atariage.com/forums/topic/276328-gates/?p=3981450 In what you quoted I would ask you to focus on this part: Now here is that part with some extra help: That CBS ram is always zero is simply not true. The other emulators got it wrong. This issue is resolved.

I don't have alot of carts anymore, but here's what I remember about Dig Dug. The Super Chip ram was dirty. If you have that cart please give it a dump to see. It was not all zeros, and very random. CBS extra ram is also not zeros. Here's an old post I made 8 years ago which has interesting insights into CBS ram (FA bankswitching). Also this post I made in the same thread mentions other FA dumps on the net which had different values in the ram. I investigated old dumps from Rom Hunter's V1 collection (long, long ago). Some of the FA dumps had $FF and $7F in the ram locations. Others had $F0, $F4, and $FC. So it does not appear consistent or reliable, and certainly not all zero's. IMHO ram should be cleared, or be feared...

It can't easily be adapted as the Super Chip ram is on the cartridge, not on the console. Also all the consoles I tried had non-zerod ram (4 switch, 6 switch, Atari Jr.). The exception was a Colecovision with a 2600 adapter.

Commando Raid (Carrere Video): Commando Raid (Carrere Video) PAL.bin

I made a test rom and tried BFSC and it works on the Encore. This is sixty four 4k banks with super chip ram. BFSC_Test.zip What is interesting is while loading the Harmony logo disappears and is replaced by an 'e' for Encore. Very nice touch and I haven't seen it before. Must only appear for bankswitching schemes that the Encore can do? In the zip file above is a video of it in action.

Those other larger bankswitching formats may very well work, but I'm just focusing on 3E at the moment. These are all the 3F games I know of: - Espial - Miner 2049er - Miner 2049er Vol II - Polaris - River Patrol - Springer All are 8K. Going with that I made some new 8k roms with different amounts of ram: - 8k rom, 16 ram - failed (would not load) - 8k rom, 32 ram - failed (would not load) - 8k rom, 64 ram - failed (would not load) - 8k rom, 128 ram - failed (would not load) - 8k rom, 256 ram - failed (would not load) I thought about this and released I had already found that a 32k rom and 16k ram worked, so the 8k rom with 16k ram failure was interesting. I went down a path of thinking that 32K rom plus 16 ram x2 (read/write addressing) = 64K, so maybe the size of both together matered in a way it gets stored in the encore memory. Perhaps the non-loading is due the Encore not starting up in the last bank as defined by the spec, because the size is not what was expected. On that note I experimented next by making a 64k rom with a 32k ram, but it would not load too. So that's where we are.

I tried: Harmony 1.06 BIOS (beta) Same results as before. 32K Rom and 16 Ram maximum for 3E. This version also has garbled characters on the menu screen. Harmony 1.06 BIOS (beta 2) No change for larger size in 3E. Garbled characters is fixed. Harmony 1.06 BIOS (beta 5) No change for larger size in 3E. Harmony 1.06 BIOS No change for larger size in 3E. I'm assuming this is the official release version, but is it the latest? I updated these all with .cu file, and made sure that only the new hbios was on the root of the SD card. I also checked subfolders to make sure no hbios files were in there. One other thing I wondering is if the eeprom file is different for Encore.

I tried a 64k, 128k, 256k, and 512k rom. All fail to load. I looked at the firmware version on my Encore screen, and it is 1.06. I am now going to search and try uploading the lastest eeprom and bios files to my Encore. If anyone can say for certain they now what should be used on the Encore please say so.