All Activity

Hi All, Here is a different HIRES program, it is not the same as the XB version, as I no longer have any other data than the listing, I cannot comment on all it's functions as yet. The paper was torn on one number but I figured it was a 2 by the left over parts, Line 10030, the "2" was at second from the end. I hope it works OK, if some one dissembles it, that should clear up it any issues. Regards Arto. 100 REM ***************** 110 REM * HIRES ROUTINE * 120 REM * MINIMEM +32K * 130 REM ***************** 140 REM * BY ARTO HEINO * 150 REM * 10/3/86 * 160 REM ***************** 161 REM *VARIABLES USED * 162 REM * X=1 TO 255 * 163 REM * Y=1 TO 191 * 164 REM *SET=1(ON)0(OFF)* 165 REM * START=MEMLOC * 166 REM * FINIS=MEMLOC * 167 REM * A,B,Q=SUBRTN * 168 REM ***************** 169 REM *DO NOT INCLUDE * 170 REM *ANY REMS OR ANY* 171 REM *STRINGS IN YOUR* 172 REM *PROGRAM********* 173 CALL CLEAR 180 REM *INITIALIZE LINK* 190 GOSUB 10000 200 REM *SCREEN MEM LOCT* 210 START=9216 220 FINIS=15360 230 REM *CLR SCREEN MEM.* 240 GOSUB 11000 250 REM *POINT X,Y,SET * 260 X=128 270 Y=100 280 SET=1 290 GOSUB 12000 300 REM * LINK ROUTINE * 310 CALL LINK(HIRES") 320 REM * PRESS FUNC 9 * 330 REM *RETURN TO BASIC* 340 REM *RESTORE CURSOR * 350 CALL POKEV(1008,255,129,129,129,129,129,129,255) 360 END 9999 GOTO 9999 10000 CALL LOAD(28702,127,224,"",32736,72,73,82,69,83,32,125,0) 10010 CALL LOAD(32000,2,224,112,184,2,0,0,2,4,32,96,52,2,0,2,6,4,32,96,52,2,0,3,255) 10020 CALL LOAD(32024,4,32,96,52,2,0,4,3,4,32,96,52,2,0,5,54,4,32,96,52,2,0,7,15) 10030 CALL LOAD(32048,4,32,96,52,2,0,24,0,4,194,4,193,4,32,96,36,5,128,2,33,1,0,2,129) 10040 CALL LOAD(32072,0,0,22,248,5,130,2,130,0,3,22,243,4,192,4,193,4,32,96,36,5,128,2,128) 10050 CALL LOAD(32096,24,0,22,250,2,0,32,0,2,1,79,79,4,32,96,36,5,128,2,128,56,0,22,250) 10060 CALL LOAD(32120,2,0,27,0,2,1,208,0,4,32,96,36,2,0,0,0,2,1,36,0,2,2,24,0) 10070 CALL LOAD(32144,4,32,96,40,4,224,131,116,4,32,96,32,192,96,131,117,2,129,0,15,22,249,2,0) 10080 CALL LOAD(32168,0,0,4,32,96,52,4,224,131,124,4,91) 10090 RETURN 11000 FOR CLR=STRART TO FINIS STEP 32 11010 CALL LOAD(CLR,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0) 11020 NEXT CLR 11030 RETURN 12000 A=INT(X/8)*8+INT(Y/8)*256+(Y-INT(Y/8)*8) 12010 B=X-INT(X)/8)*8 12020 B=-(B=0)*128-(B=1)*64-(B=2)*32-(B=3)*16-(B=4)*8-B=5)*4-(B=6)*2-(B=7) 12030 CALL PEEK(A+START,Q) 12040 B=B-((Q+B<256)*(SET=1))*Q+((Q-B>-1)*(SET=0))*Q-((Q+B>255)*(SET=1))*(255-B) 12050 CALL LOAD(A+STSRT,B) 12060 RETURN TIDrawMM1a

I wonder what the actual failure rate is for Haunted House. If it's high enough, a proven working copy might be more valuable. Unfortunately, the only way to prove it works is to open it, making it less valuable to collectors. Hmmm, maybe someone could write a book about that...

Yesterday's (5/13) totals: Android 1) Retro Bowl - 20 minutes SNES / Super Famicom 1) Al Unser Jr.'s Road to the Top - 65 minutes

My sentiments exactly. Because I am not good when it comes to modern computers and modern programs. So I’m hoping a dedicated thread will start where people can post and share premade plug and play files, similar to how rom files are posted for the special SD card cartridges. I want the 3 main “staples”. Raiders of the Lost Arc, Star Wars, and Back to the Future. 🙂

Fixed

Ok thanks I understand. Well your window might be the screen size, but it makes sense. When you gave example of changing a palette value in the SCB, I might have assumed that possible. Also changing the data in the array used to change the actual sprite. I haven't tried either though. If it did work, I gather it shouldn't be during draw like anything else.

Just about everything that could happen to the Atari lynx power regulation demonstrated right in your face, and explained in a manner that it hasn't been before, even if it was thought to have been

This is not correct, SUZY chip can handle a virtual window bigger than the physical screen, and at this window can be applied X and a Y offsets (changing the offset the screen image can slide without changing the single sprites coordinates). This means that you need signed values for the sprite position, and they must be signed integers because signed chars are too small. It's up to you to prefer memory saving or performance boost. Chained sprites are much faster.

@Tursi There is some lady here to see you... says her name is Sarah Connor.

I've always found it interesting at what is and what isn't acceptable in each country to show on TV or in film. For example and correct me if I'm wrong, but as lax as Japan is on nudity I believe that it is (was?) illegal to show pubic hair. You could do that in the US as long as it was in an adult movie or magazine. Just some of the quirks from country to country.

Oh man! It's game over for Nintendo! John fixed cornhole a little more!

You can apply for the job at your local UPS store. It's simple. Players alternate throwing. Bag in the hole is worth 3 points while bag on board is 1. Scoring is done like this. You sink one bag for 3pts and have two more on board (total 5 pts). I sink two bags and get one on the board (7pts) for that round I get 2 points. You play to whoever gets 21 or more points.

I would need a turbo button for sure. I don't like having to rapidly press a button a hundred times over and over.

Its ironic that you need a somewhat powerful modern machine in order to encode movies that will play on a VCS I hope people do share some things that they encode.

I've seen a white label for Tron online from other sellers. There must have been different labels for that game. As for the Astroblast label, I had to make one because the original fell off. The photo showed it before I bought the lot. But once the games arrived, the Astroblast one was missing. Tron Deadly Discs comes in a blue label and white label. I don't mind the white label. Although I prefer the blue one. https://www.ebay.com/sch/i.html?_from=R40&_trksid=p4432023.m570.l1311&_nkw=atari+2600+tron+deadly+discs&_sacat=0

Sad news to hear this. Hopefully Atari can make it right like they did the other issues with their carts.

Ok, maybe not in this thing, but in my first game I have used the same data array across different 1 bit SCB structures so that colours don't have to be changed. I wonder now if memory permitting, it would be better to make copies of the same sprite just so that it can be chained, if a number of the same "baddies" are on the screen. Right. I understand it is kind of what I thought. Working like a linked list so Suzy should not have to wait for CPU anymore. It is not used for the purpose I thought. I assumed it was to do with cycling animation frames of one moving character. You'd be moving all of the sprite position coordinates directly in the movement part. I get it. So followup... I'll bet the position members of the SCB structure are 16 bit signed integers. No dimension of the display exceeds 255, so it's easier for an 8 bit CPU to track everything on a screen as unsigned bytes. Parts of sprites still appear on screen when they are below zero for either coordinate, so a screen position can still be stored in a pair of bytes for a typical sprite as the width of the sprite + x position, and, height of the sprite + y position. Then when it comes to drawing, subtract the sprite width or height from the 16 bit integer for Suzy. My question is basically, is worry about that kind of overhead a complete waste of time? I'm guessing it is still graphics drawing that ends up choking the speed of a typical game rather than CPU calculations.

I will test on my real nes with famicom adapter tonight and report back..

If you want to experiment with sprite flicker techniques in the bB Multisprite Kernel, it would probably work out better if you disable the original code first. The original code does a pretty decent job outside of a couple of edge cases... Literal edge cases, where a sprite goes off the top/bottom of the screen. I was looking at ways of trying to fix that a few months ago. As for 'drawscreen' / 'drawsprite': I agree that it would be nice to have stack-able kernels. It wouldn't necessarily be a performance issues... more of an implementation issue. The bBasic compiler would need to be modified quite a bit to support it. The drawscreen command is relatively straight forward; it does a subroutine call to the display kernel. The display kernel code does all the heavy lifting of video frame management: handling VSYNC, the VBLANK at the top of the screen (where kernel preparations are done), and running the display kernel to draw the screen. If you want more flexibility, all that would need to be broken apart, at the very least into 'startvideoframe' and 'drawkernelrow' functions. That's partially what lead me to developing Neolithic C : the ability to play around with video frame loop code from a blank canvas. These sorts of things can be done in bBasic as well, but require changes that can fit in without breaking what's there.

Yep, I've been quite a few times and I've seen the maintenance tech working on the occasional down cabinet, so they're definitely on top of it. The only game that is frequently down is Dragon's Lair. Other than that, I can't recall any other games ever not working except very temporarily. They do a nice job with it.

Stella 6.6_ _vcsbeatbox-rc22-ntsc_ 2024-05-14 22-15-26.mp4 It's a great little program! 4 instruments, 3 patterns and 16 bar sequencer. Fun to program in the loops and watch it go. Amazing it fits in 4K. Well done.

Just in time for my almost finished nuc! Thanks!!!

The idea was to have a constant number of sprites to draw (or not) I tried to avoid speed slow down where the number of bubbles increase. Unfortunately, it seems to be a fail