Omegamatrix

I've now checked all the games up to game selection number 87 (the unknown Datatech game). Sku_u never made a list of the games before, but he did mention game selection 87 was the unknown game so it seems to align. I'm 99% sure it's going to be the same, and I will check the rest over time. It's surprising how long it takes just to check all the games. Eventually I should be able to post a listing. Game selection number 50 keeps giving me a black screen. From the rom dumps Sku_u posted I think it might be Haunted House. I have a feeling there is a bug in the game that the Screen Search is exposing.

Yep. Yeah its NTSC format. Oddly enough there is no switch populated for the channel 2-3 select. You can see in the pics there is a cutout for it, but looking inside the cutout there was no switch ever installed. Yes. It was dumped and released long ago.

BTW Atarimania still has picture of the box for the console. I don't have a box or anything. The photo must be from the original ebay auction photo that sku_u won. Kind of a funky box. I like it. http://www.atarimania.com/game-unknown-game-2-datatech_s12661.html Looking at the serial numbers of both known consoles it seems likely to me that the first two digits of the serial number represent the year. '90 or '91 seems about right for a console like this. The rest of the numbers in the sequence, who knows? My serial number is 900347905. (Note the font for the zero in 90 looks different then the other zeros) Sku_u's number is 910450044.

Yes the pictures are free to use. No manual unfortunately. I'm pretty sure the power supply and controller I got were not original to the console either. I haven't checked it very much, but everything so far looks the same. Thanks Shawn. It works. I've played a few games off of it.

I picked this up today at a local store. I was pretty excited to do so. This is the console that contains the unknown Datatech game. I read a few of the old threads about it, and yep game selection 87 is the Datatech game. AFAIK only one other Screen Search console has been found. The Datatech game was also on a pirate cart, and I think there was also only ever 1 copy found of that. All in all a cool find. It's a Holy Grail for me. Here are some picks:

I got one... Why don't you???

Self modifying code is very useful. I've done it many times myself as have others. In your example there does not seem to be many different values, and maybe you are doing too much for what you need. Have you considered just indexing like the example below, not running in ram? ldy siIndex lda SiLineTab,Y cmp scanline bne .skipUpdate lda RegValTab,Y ldx RegIndexTab,Y sta 0,X .skipUpdate: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; RegIndexTab: .byte COLUP0 .byte GRP0 .byte ENABL .byte HMP1 RegValTab: .byte 0 .byte YELLOW .byte %10101010 .byte $02 SiLineTab: .byte 0 .byte 131 .byte 110 .byte 108 Alternatively, you could also stick the look up tables in ram, and keep the routine in rom. If you are limited on ram and have lots of cycles then just keep the next value from each table to be used in ram (1 byte per table).

I've seen many solutions to this before, having interest in division routines myself. The one solution Crispy posted is similar to the ones I saw. The one I'm posting is untested, but I think it works. It gets the job done albeit a little slow.

Maybe, but maybe not. Is this Jr made in China? Does it have a date on it? The real problem with these oddball consoles is that HMOVE's in the visible portion of the screen (including cycle73/74) will corrupt the graphics. If the position of the players on the previous line is always the same that is good as it does seem a HMPx value can be found that works. However there is still a chance that the graphics get corrupted so that becomes difficulty to deal with. I'm going off of what I understood from Eckhard, quoted below.

Here try this test rom built around cycle 74 HMOVE's.: DHmoveValues(rev2).zip Use the joystick left & right to slow/speed up the cycling. While looking more at early HMOVE's several months ago (for my new game) I found 2 very important posts: http://atariage.com/forums/topic/72308-hunchy-ii/?p=903045 http://atariage.com/forums/topic/72308-hunchy-ii/?p=903928 It does not appear viable to get correct the HMxx values for every system, because even if you get the position correct there will be shifting that can corrupt the graphics. This will be true on late model Atari Jr's and all PAL 7800's for any HMOVE's during the visible portion of the screen. That being said I am still using early HMOVE's myself.

Edit: Nevermind I thought you were asking if any bit was set.

There are also Amiga and ST versions included in the zip file.

Definitely a hidden gem. If you like, try the Track Ball version too!

Some really good choices already for the old era games. Ithink H.E.R.O. looks amazing for a 2600 game. For pushing hardware to the limits, I think Meltdown, the Care Bears game, and Kabobber, and Rocky and Bullwinkle are all worth a mention although they are protos. Meltdown did tricks with NUSIZx, Care Bears with REFPx, Kabobber with RESPx, and Rocky and Bullwinkle used early HMOVEs. For homebrews I would say Thrust+ still is pretty advanced and still holds up today. I am impressed with the scrolling in it, and how it does not distract. Strat-o-gems also has some nice features like the logo shine, and replays. Anything Supercat does is great stuff. He is one of the best programmers for the 2600. For homebrews using the ARM I would give the nod to SF2. There is a crazy amount of stuff going on there. I know Draconian is doing more with CDF (like speech samples in game), but there are many creative surprises in SF2.

With the GCC Millipede I would be happy just to have it in NTSC. I've done some work on it before and I know Thomas has too, but neither of us have done anything for the trackball. I just took a look and I have a rom I made that got it down to about 290-291 lines on the playing screen. So still not very good. If we could get it down to around 272-280 it would be better, but I don't know if we could ever get it to 262 very easily. Anyhow I'm working on too many things right now to really even take a look, unfortunately.

You should also include what is available outside TIA. Off the top of my head with the proper setting and kernel implementation these should all be available: - Stack Pointer (1 byte) - INTIM (1 byte) - TIMINT (1 bit) - Status Register (4 useful bits - the interupt flag, overflow flag, decimal mode, and carry flag) - SWCHB (the 3 unused bits - D5, D4, and D2) - The upper 3 bits of the high address of the Program Counter RevEng's idea of dumping the latches is also a good one that I never considered. I did not include SWCHA as those bits can be pulled down by a control. However thinking about it now I did use the right port for storage in all of my trackball hacks. With SWCHB I have tried it and it works although someone pointed out it is shortening those bits to ground so I went away from it. One of the most useful ways to preserve bits is to use the high three bits of any pointer address as they are all mirrors. I've used that in some of my hacks when ram was limited, but my first goto's are always the stack pointer and timer as they give a whole byte each and are usually easy to implement.

I either did this or was going to do this in one of my hacks. I can't find or remember the rom though. It was a weird situation where I just needed a few bits more of ram. This was long ago...

It does not have to be monochromatic. There are enough cycles to update the background color and player color each line. .loopKernelA: sty GRP0 ;3 @4 starts at cycle 1, not 0. sty GRP1 ;3 @7 sty COLUBK ;3 @10 sty COLUP0 ;3 @13 sty COLUP1 ;3 @16 sty COLUPF ;3 @19 for pixel drawn by the ball sty ENAM1 ;3 @22 sta RESP0 ;3 @25 sty GRP0 ;3 @28 sta RESP0 ;3 @31 sty GRP1 ;3 @34 sty GRP0 ;3 @37 sty ENAM1 ;3 @40 sty GRP0 ;3 @43 sta RESP0 ;3 @46 sty GRP0 ;3 @49 sta RESP0 ;3 @52 dex ;2 @54 line count sty GRP0 ;3 @57 sty GRP0 ;3 @60 sta RESP0 ;3 @63 sty GRP0 ;3 @66 sty GRP0 ;3 @69 sty GRP0 ;3 @72 SLEEP 2 ;2 @74 bne .loopKernelA ;2³ @76/1 .loopKernelB: SLEEP 4 ;4 @5 starts at cycle 1, not 0. sty GRP0 ;3 @8 sty GRP1 ;3 @11 sty COLUBK ;3 @14 sty COLUP0 ;3 @17 sty COLUP1 ;3 @20 sty COLUPF ;3 @23 for pixel drawn by the ball sta ENAM1 ;3 @26 A=0, disable sty GRP0 ;3 @29 sta.w RESP0 ;4 @33 sty GRP0 ;3 @36 sta RESP0 ;3 @39 sty GRP1 ;3 @42 sty GRP0 ;3 @45 sty ENAM1 ;3 @48 sty GRP0 ;3 @51 sta RESP0 ;3 @54 sty GRP0 ;3 @57 sta RESP0 ;3 @60 dex ;2 @62 line count sty GRP0 ;3 @65 sty GRP0 ;3 @68 sta RESP0 ;3 @71 sty GRP0 ;3 @74 bne .loopKernelB ;2³ @76/1 It is also real close to having AUDV0 updates. The problem is there are only 2 cycles left in Kernel A. Of course dropping either the COLUBK, or both COLUP0 and COLUP1 updates would still allow 1 color update per line and audio updates. You could also do two line kernel where you just update COLUBK one line, and the player colors on the second. Then you can do AUDV0 updates every line with color changes.

Zack, I wrote a testrom for your kernel. It works fine in Stella although I haven't been able to test it on real hardware yet. Well done Zack. This test rom turns off a single bit column at a time. You can change the selected bit by using the joystick. This is not bus stuffing... just a testrom using zeropage ram. 160_Bitmap_201805022.zip I'm really looking forward to seeing a full bitmap image done with bus stuffing.

I think that will work brilliantly. With interlacing, consider a multiline kernel as shifting left by 8 with an early HMOVE is always nice for hiding the comb.

Unfortunately this kernel was never meant for a 144 bitmap. There are lots of gaps between the characters. I do have some ideas to explore for getting to a 144 bitmap or larger, but I haven't tried them yet. In the meantime these character kernels are fun to do, and can make some nice text displays.

Today I made an interlaced version of the 36 character display. 36_Char_Interlaced_201805020.zip This is a perfectly aligned 36 character demo running on stock hardware. It is a mock up for CDF or DPC+ which is where its usage becomes practical. The screen color is black to hide the ball and the HMOVE bars.

Even though there seems to be lots of cycles with bus stuffing, I think as soon as you play with missiles it becomes tricky. I haven't looked at this yet.

I made an instruction screen demo. I found I could get 13 rows comfortably in for NTSC. Hardware assistance would allow many more. 36_Character_Demo_Instructions.zip

Maybe... as it is there are essentially two kernels. Currently to get the perfect alignment you have to use the 'B' kernel which has all immediate loads (at 275 bytes per row!). However the 'A' kernel can still be done using the original 'A' kernel which loaded from zero page ram. That would allow good byte savings. The 'A' kernel also uses 5 bytes less of zero page ram. So yeah it could be done, but to get several lines it will cost a lot of rom. Still games are getting larger all of the time so maybe this really isn't a barrier. Overall you could still just use CDF or DPC+ and do it without wasting gobs of rom.