DZ-Jay

I was trying to remember what the little birdie said about the new IntyBASIC, but I can’t recall it … My memory is fragmented and it feels like it takes a lot of effort to bring the various pieces together … All those scattered segments in my brain … If you could only read my memory .... 🤔 dZ.

You are very late! You need to put some Christmas lights on that pumpkin. 😄 dZ.

Good point. It was moving so fast I thought it was flying. dZ.

A little birdie came to me a few weeks ago and told me that the new IntyBASIC was going to have a very cool new feature. I was very excited until I realized that little birdies do not talk, so I thought I must have dreamt it. Just the other day, the birdie came back and told me, "it is ready." Actually, it said something more like, "¡Órale, wey! ya 'ta listo." Apparently, this little birdie is Mexican. 😏 -dZ.

Implementing Bresenham's algorithm in intyBASIC is easy. My "Draw Circle" library uses a variegation of it and it is purely in IntyBASIC. It may just be a bit slow to do so for general lines. If you are looking to detect line-of-sight, there may be better ways. In my case, I could take shortcuts due to certain assumptions in my motion routines. You may be able to take similar shortcuts. For what you are describing, you would probably need a rather big table to store all combinations of distances and slopes. I'm not sure it is worth it. dZ.

In that case, it is very simple: ' Screen #CurrLevel 0, 0, 20, 12, 80 ' R0 = Rows ' R1 = Columns ' R2 = BACKTAB origin address ' R3 = Pointer to source table ASM MVI #var_&CURRLEVEL,R3 ; Source in #CurrLevel ASM MVII #512,R2 ; Origin (0,0) ASM MVII #20,R1 ; Screen width ASM MVII #12,R0 ; Screen height ASM CALL CPYBLK ; Copy dtatat from source to BACKTAB -dZ.

Ah! Of course, hacking IntyBASIC is always an option -- I keep forgetting. -dZ.

I understand. You should be able to use "ON CurrLevel FAST GOTO ..." to support each of the specialized functions needed for the levels. For example, the following uses a construct that simulates a "Select Case" switch used in other flavours of BASIC to initialize all levels individually, along with performing some common initialization that applies to all of them. If you do not have anything common, you can replace all the "Goto .CaseEnd" with "Return" to break out of the routine when the initialization of a level is done. ' Initializes a level InitLevel: Procedure .SelectCase: On CurrLevel Fast Goto, .Level1, .Level2, .Level3, .Level4 .Level1: Screen Level1, 0, 0, 20, 12, 80 ' Do other level 1 specific stuff Goto .CaseEnd .Level2: Screen Level2, 0, 0, 20, 12, 80 ' Do other level 2 specific stuff Goto .CaseEnd .Level3: Screen Level3, 0, 0, 20, 12, 80 ' Do other level 3 specific stuff Goto .CaseEnd .Level4: Screen Level4, 0, 0, 20, 12, 80 ' Do other level 5 specific stuff ' Goto .CaseEnd .CaseEnd ' Do common stuff for all levels here: ' ... Return End You can use a similar pattern for your scrolling routines. Note that "On x FAST GOTO" is rather fast -- much faster than using an IF/ELSE/END. (The "FAST" modifier removes any bounds checking of the test variable, so you must make sure that every single value it supports must be represented by a label in the statement.) NOTE: The upcoming version of IntyBASIC will include a new "Select Case" statement, which will make the above code a bit cleaner. It may not be a bad idea to start getting used to that sort of construct. :) -dZ.

Hi, @YannAros, Unfortunately, this does not seem possible -- the documentation specifies that SCREEN takes either a label, or an array, but not a pointer. If you want to encapsulate the SCREEN invocation so that you only have to define it once, then you could do this via a GOSUB procedure. -dZ.

It's been quite some time, but I believe I got mine right after PRGE, when BBWW return from the convention and sold to those who did not attend. I believe the manual, box, overlays and everything else came afterwards. In fact, I just found an old thread in which BBWW was ranting about someone making money off the game by selling boxes without authorization. -dZ.

Nope. Just an old cartridge and a skanky lollipop. -dZ.

I have my original baggie, still unopened, and completely forgot about the bacon lollipop. I see that it is still in there, but I would hate to think what sort of cooties that thing has acquired over the years! 😬 I don't dare find out, but it must have a very unique and funky flavor by now. Eek! dZ.

The listing says: Pre-Release due out 12/31/2024 in UK (This item will be delivered after the release date) So it seems the console will be released at the end of the year? I haven't been following this fiasco, so I don't know the status of the project. I thought it was cancelled. dZ.

Ask Clyde if he would mind coming over for a play session at my house. dZ.

No worries. Here is a bit more context. Consider that the memory map is one huge block, organized into 16-bit words, each one with an address. The addresses are arranged in numerical order, starting at $0000 and ending at $FFFF. That entire range is fragmented into individual blocks reserved for hardware devices, the EXEC ROM, peripherals, etc. All that means is that the memory available to store a program is scattered across many separate blocks all over the map. Back in the Mattel days, this wasn't a problem; the $5000 - $6FFF range was 8K and that was the maximum that cartridges supported, and a 4K or 8K program could fit comfortably in there without spilling over. Our home brewed programs are larger now, so we have to find other blocks of memory to store the overflow. That is where the additional segments come in. Those blocks are just the memory addresses that Mattel intended to use for expansion, but never got around to using, so they are free for us now. dZ.